看懂一个完整 Agent 怎样完成任务

　　欢迎来到《进阶 vibe coding》。当我们已经会使用 AI、也能把模型接进程序，接下来要学的是：怎样让 AI 更好地完成复杂任务。 这需要理解模型的能力与局限，也需要理解一个助手怎样获取信息、采取行动，以及怎样与人合作。

　　第一课先对课程整体有一个明确的认知。我们沿着一项客户工单分析任务，从模型的一次回答出发，逐步加入检索、工具和人的反馈，看看一个 Agent 怎样取得资料、调整行动并形成结果。

　　后面的课程会逐步深入这些环节，看看不同任务下，AI 应该怎么用、为什么要这样用。贯穿练习会以小说创作 Agent 为例，用小说工作台观察上下文、工具、反馈和人的参与怎样配合。我们学习这些方法，是为了在自己的任务中更好地理解、组织、扩展和改进 AI。

模型根据上下文处理当前任务

　　设想我们希望 AI 完成一项工作：“分析本月客户工单，找出值得优先处理的产品问题，写一份改进建议。”模型可能知道怎样分析客户反馈，但本月具体发生了什么，还是需要从我们的业务资料中取得。

　　把一批工单交给它，它才有了分析对象。任务要求、工单内容和补充的产品背景，共同构成这次生成的上下文。

　　模型通过训练获得通用能力，再结合上下文处理具体问题，比如比较描述、归纳问题、组织建议。我们写下的要求只是上下文的一部分，提供什么资料、怎样组织这些资料，同样会影响结果。

　　这些信息进入常见的文本生成模型后，会被切分成 token。注意力机制会参与计算这些 token 之间的关系，模型据此逐步生成后续内容。

　　于是，这里也就自然延伸出了两个问题：上下文能容纳多少信息，以及模型能否有效利用这些信息。选择材料时，我们既要考虑输入容量，也要考虑哪些内容真正有助于当前判断。

工具让模型取得需要的资料

　　要回答最初的完整问题，手边这批工单还不够。我们可能还需要查询其他工单，或者对照产品文档确认某些投诉。与其每次都由人先把资料整理好再交给模型，不如让它在需要时自己去取得。

　　不同资料，获取方式也不同。按月份、客户或数量查询工单，可以直接调用数据库；寻找“登录失败”对应的产品说明，则更适合使用关键词或语义检索。语义检索常借助 Embeddings，把文本转成可以比较相似度的向量。把检索到的内容补充进上下文，再让模型继续生成，就是 RAG（检索增强生成） 的基本思路。

　　再往前一步，我们可以把查询工单、检索文档这些能力直接提供给模型，作为它可以调用的工具。应用把任务和可用工具的说明交给模型，模型判断需要什么，并返回要调用的工具和参数；应用执行后，再把结果交回模型。这样，信息就不必在任务开始前一次性准备好，而可以随着任务推进不断补充。

　　当需要连接的系统越来越多时，MCP 可以提供一套统一的连接方式，让助手发现并使用外部系统提供的工具和资料。数据库查询负责取得工单，MCP 负责把这些能力连接进来，模型则负责判断什么时候使用，以及怎样利用返回的内容。它们解决的是同一项任务中的不同问题。

Agent 根据新信息调整下一步

　　取得第一批工单后，事情未必就结束了。假设“登录失败”的反馈很多，我们可能还要继续查看它集中在哪些版本、哪些客户，再决定问题是否值得优先处理。也就是说，下一步要查什么，往往取决于刚刚查到了什么。

　　让模型在目标下选择行动，执行工具后读取结果，再决定继续、求助或结束，这就是本课所说的 Agent（智能体）。相比一次生成直接给出结果，Agent 会通过多轮生成与执行逐步推进任务。

　　不过，任务并不会全交给 Agent。假如反馈中混有内部测试账号，是否纳入统计就涉及业务口径。当我们决定只分析真实客户时，这个判断就会进入后续上下文，Agent据此调整查询。到了建议排序时，我们也可以补充近期产品目标，再一起讨论优先级。人在环路就在这些地方发生：人的知识和判断进入任务，并影响 AI 接下来做什么；必要时，也可以暂停或接管。

　　至于让 AI 自主到什么程度，要看任务本身。每月固定统计各类工单数量，步骤比较明确，更适合用工作流预先规定；调查某个异常现象，下一步并不确定，则更适合让 Agent 根据结果继续探索。实际应用中，两种方式也经常结合使用。我们需要在任务效果、时间和成本之间做出取舍。

Harness 支撑整个任务的运行

　　Agent 做出下一步判断后，任务还需要继续运行：调用选中的工具，保存取得的信息，等待人的回复，再把这些内容组织进下一轮上下文。围绕模型完成这些工作的软件，通常称为 Harness。

　　这也解释了为什么同一个模型放进不同助手，实际表现会有差别。工具决定它能做什么，上下文管理影响它每轮看到什么，状态管理则让任务能够中断和继续。模型之外的这些机制，共同决定了 Agent 怎样运行。

　　把刚才的任务连起来，就能看到工具结果和人的反馈，是怎样经过 Harness 回到模型，形成下一轮判断的：

Skills 和插件让工作方法得到复用

　　当一套任务已经跑通，下一次往往还会用到相同的筛选口径、分析方法和报告格式。与其每次重新说明，我们可以把这些方法、步骤和样例整理成 Skill（技能），让助手在处理同类任务时按需读取；相关资料和脚本也可以一起保留下来。

　　在工单分析中，工具和 Skill 承担的作用并不一样：工具负责查询、读取、生成文件等具体动作，Skill 则告诉助手这类任务应该怎样分析、按什么步骤完成。两者配合，既能做事，也能复用已经验证过的工作方法。

　　如果宿主支持插件，还可以把相关的 Skills、MCP 服务和配置组合在一起，方便安装和复用。比如一套客户反馈分析插件，可以同时带上工单连接、分析方法和报告模板。模型仍会根据这一次的资料作出判断，但我们不必再从头说明整套做法。

　　一些已经确认的重要口径，也可以保存下来，在后续任务需要时重新加入上下文。

从这幅全景选择学习方向

　　到这里，一项原本只是“把文字交给模型”的任务，已经逐渐变成了：取得资料、分析问题、继续补查、与人讨论，再形成结果。不同能力解决不同的问题，真正重要的是知道什么时候该用哪一种。

　　这种分工并不只存在于工单分析里。文档助手、编码助手和各种业务工作流，本质上也在组合这些能力。后面的课程会沿着这些问题继续深入，并通过不同任务观察它们怎样配合。

　　主线课程按问题逐步深入。涉及前面成果的实践会说明必要前置，有同等经验时也可以从相应位置进入；应用方向则按自己的任务选读。代码实验使用 TypeScript，并在各课给出可运行的起点、已有材料和结果核查方式，方便修改条件、反复比较。课程实验共用一个仓库和启动入口，首次准备见下方说明。

　　真正用好 AI，往往就体现在这些选择上：什么时候一次生成就够，什么时候需要检索或持续行动，又有哪些判断应该由人参与。

　　接下来，我们从 token 开始，先看看模型究竟怎样处理输入，再进一步理解怎样为它提供更有效的信息。