从回答问题到帮你做事，Agent 多做了什么？
沿着一次周报整理，理解 Agent 如何选择动作、使用工具、接收反馈，并在需要时停下来。
“帮我把这件事做完。”
这句话里，我们期待的帮助，比回答一个问题多了不少。对方需要知道要完成什么，找到必要的信息，遇到变化时调整做法，最后告诉我们结果。如果中间缺少条件，也应该把困难说清楚。
当这句话交给 AI 时，事情是怎样发生的？
模型原本就能给建议、写文章、分析材料。为什么有的产品还能查询资料、修改文件，并根据查到的情况继续处理？是换了一个更强的模型，还是在模型之外，多安排了一些东西？
理解 Agent，可以从这里开始。我们用“整理一份周报”作为教学例子，一步步看清：一句要求怎样变成实际动作，执行结果怎样影响下一步，以及为什么有时候停下来，反而更接近把事情做好。
1、先弄清楚，我们希望它多承担哪部分工作
先比较两种要求。
“周报应该怎么写？”需要的是写作建议。模型可以介绍结构、提醒注意事项，回答到这里就已经有用。
“根据这些笔记，写一份周报草稿。”则需要它处理你提供的材料。模型可以归纳进展、调整措辞，再把结果交回来。
但如果要求变成：“根据本周笔记整理周报，遇到进度不清楚的地方，查一下对应任务；仍然无法确认的，留给我判断。只生成草稿，先不要发送。”
这里就多了一段过程。笔记里有哪些信息不够？该查询哪个任务？查完能不能解决疑问？如果不能，下一步怎么办？
如果这些事情全部由人来安排，就需要人不断接手：读回答、发现缺口、去查询、补材料、再提问。模型参与了处理，任务怎样继续仍然由人一步步推动。
Agent 希望接过其中一部分推进工作。
在本文讨论的意义上，Agent 是一种由模型参与决定下一步、借助工具执行动作，并根据执行反馈继续处理任务的系统。 它围绕一个目标工作，也受到程序和权限的约束。
这个定义里有三个需要连起来看的部分：作出选择、实际执行、取得反馈。只列出几步计划，过程还没有开始；只接通一个工具，也没有说明它会怎样根据结果调整。
还要留意，聊天窗口只是外观。同样在对话框里使用的产品，背后也可能运行着 Agent。判断时要看任务怎样推进，不能只看它是不是以聊天的形式出现。
2、模型说“我来查询”，查询为什么能真的发生
继续看周报。先限定这个例子的能力：应用能够读取用户选定的笔记，也提供查询指定任务记录的工具；本次只整理草稿，没有发送权限。
这里的“工具”，可以先理解成程序提供的一项具体操作。查询任务，就读取相应记录；保存草稿，就把内容写到指定位置。工具并不一定使用 AI，它负责完成明确的操作。
应用会把目标、已有材料，以及可用工具的说明交给模型。工具说明需要告诉它：这项操作能做什么，使用时必须提供哪些信息。模型据此选择是否请求某个工具，以及查询哪一个任务。
这个请求也不是随便写一句“我来查查”。程序需要能够识别它请求的操作和相应信息，才能继续执行。
比如，笔记中提到“任务 A 仍在联调”，另一条记录又说“任务 A 已关闭”。模型可以提出查询任务 A 详情的请求。接下来，由执行程序检查请求是否有效、是否有相应权限，再去读取记录。
模型提出一个动作，程序执行这个动作。两者之间，需要有真实的连接。
如果应用没有查询能力，模型写得再像在工作，也不能仅凭一句话取得任务系统里的资料。接入了查询工具，没有访问权限，也一样读不到。
Anthropic 的工具使用文档展示了这种配合：模型发出可由程序识别的工具请求，执行方完成操作，再把结果交回。执行方可以是开发者的应用，也可以是平台托管的服务；具体部署方式不同，这种职责区分仍然有助于理解过程。
所以，看到“正在查询”时，先把它理解成过程提示。有没有真的查到，要看执行结果。看到“已保存”也是一样，文字声明本身不能代替保存成功的记录。
3、Agent 怎样根据反馈，改变下一步
假设这次查询成功，返回的信息是：关闭的是一个旧问题，整个联调任务仍在进行。
执行程序把这份结果连同必要的任务信息，再交给模型。模型于是有了新的依据，可以把周报写成“旧问题已解决，整体联调继续推进”。
现在只改变一个条件：查询成功，但记录仍然不能解释进度差异。
这时，继续把联调写成“已完成”就缺乏依据。合理的处理可能是查询另一项相关记录，也可能是标记待确认，停下来向人提问。选择哪种，要看目标、可用工具和约束。
再改变一个条件：查询失败，返回的是“无访问权限”。
失败信息同样是反馈。它告诉系统，原来的办法没有取得材料。如果已有授权范围内没有其他途径，就应该说明缺少什么，请用户补充，而不能把“尝试过查询”当成“已经核实”。
这些分叉，才让 Agent 与单纯生成一份计划有了区别。下一步会随着实际结果改变，而不只是沿着最开始写下的步骤往下走。
下面这张图把一次简化循环展开。判断节点有三种去向：交付、请求动作、询问用户；动作的结果和用户的补充，都可能成为下一轮判断的依据。
Agent 根据执行反馈继续判断，也可以结束或请人补充图里省略了并行查询等实现方式，保留的是最基本的机制。在这种常见实现中，程序会多次调用模型，每一轮把相关结果继续提供给它，而不是模型在后台一直思考、自动知道外面发生了什么。
Anthropic 在《Building effective agents》的 Agent 部分中，同样强调通过工具结果等环境反馈判断进展，并允许过程暂停以取得人的反馈。
反馈让纠正成为可能，但不会保证纠正成功。工具可能读到过时记录，模型也可能误解正确材料。需要关注的始终是：结论依据了什么，以及这些依据能否支持当前判断。
4、它为什么能接着做，又为什么有时会忘
多轮处理还有一个容易被忽略的问题：下一轮凭什么知道上一轮做到了哪里？
在周报例子里，至少要保留原来的要求、已经查到的任务进度，以及哪些事项尚未确认。如果下一轮只收到一条查询结果，却看不到“只写草稿，不要发送”的约束，就可能丢失重要条件。
应用需要保存并挑选当前任务相关的信息，在后续调用中继续提供给模型。这些本轮可用的信息，通常被称为“上下文”。你可以把它理解成模型这次处理任务时能够参考的材料。Anthropic 的上下文说明也区分了当前可参考的信息与训练时使用的数据。
因此，看起来像是 Agent“记得自己做过什么”，背后往往是应用把相应记录继续带了回来。
这与模型经过训练、学会新知识是不同的事情。一次任务中取得了新信息，并不等于模型的训练已经改变；下一次新开任务时，也不一定自动保留。这取决于应用有没有保存、是否允许使用，以及是否把相关信息重新提供进去。
长期使用的产品还可能保存一些偏好和历史记录，再在需要时取用。这里先不展开实现，只记住一个区别：信息被保存下来，和信息在这一次判断中可用，是两件事。
材料也不能无限塞进去。模型一次能够处理的信息有限，长任务需要选择保留什么、怎样概括前面的过程。概括可能漏掉细节，挑选也可能不合适。这就是为什么任务越长，越值得把关键要求和已确认结果保存清楚，并在重要节点重新核实。
对开发者来说，这部分工作会影响 Agent 能否接着完成事情；对使用者来说，也解释了为什么不能只凭“它刚才答应过”就认定后续一定遵守。
5、能继续行动，不代表应该一直行动
有了工具和循环，似乎只要不停尝试，事情总能做完。
但继续看那份周报：如果任务记录始终没有更新，再查询几次，并不会凭空得到最新进度。重复同样的操作，可能只是增加等待和费用。
因此，系统需要明确什么时候结束、什么时候暂停。草稿达到本次要求，可以交付；缺少关键事实，可以等待补充；超过约定的时间或尝试次数，也应该停止并说明做到哪里。
这些条件既可以提示模型作判断，也需要由执行程序落实。比如，本次没有发送权限，就不应因为模型提出发送请求而执行。把“不要发送”写在要求里有帮助，但真正限制动作，还要依靠程序控制。
这里也要区分两种失败：一种是动作执行失败，例如查不到任务；另一种是动作成功，内容却不符合目标，例如读到了记录，却错误归纳了进度。
前者需要检查访问条件或换办法，后者需要核对理解和依据。只看“工具调用成功”，不足以判定整个任务完成。
人的确认因此有具体作用。你可以核实不明确的进度，判断措辞是否合适，再决定是否发布。一个设计得当的 Agent 应该让你看见这些需要判断的地方，而不是用一句笼统的“全部完成”把它们藏起来。
我们希望它分担的，是那些适合交出去的处理过程；遇到没有依据、没有权限，或者需要人作取舍的地方，能把问题清楚地交回来，也是一种有效的帮助。
6、普通工作流也能调用工具，差别到底在哪
讲到这里，再回头看“Agent”这个名称，就容易分辨了。
如果周报任务的步骤一直很固定：读取选定的表格，按约定格式整理，再交给人审核，那么程序事先把流程安排好就足够。这通常可以称为工作流。它可以使用模型，也可以调用工具。
工作流也能有条件分支。比如，缺少日期就请人补充，读取失败就停止。存在分支，并不自动意味着它成了 Agent。
更有用的区分，是看任务中哪些步骤由事先的规则决定，哪些步骤交给模型结合当前信息选择。需要查询什么、查询以后是否足够、要不要换一种办法，如果其中一部分由模型动态判断，就具有我们在这里讨论的 Agent 特征。
这种区分来自 Anthropic 对工作流与 Agent 的说明。实际产品可以把两者结合：总体流程固定，在某个需要灵活处理的环节，让模型选择下一步。
所以，不必把它们排成谁更高级。步骤稳定，预先安排通常更便于控制；情况变化多，给模型一定选择空间才更有理由。多出的灵活性，也会带来更多需要检查的判断，以及额外的等待和成本。
“调用了多少工具”“有几个 Agent”，都不足以单独说明一个应用是否合适。先看它如何处理任务中的变化，再看这种安排有没有改善结果。
7、理解了原理，再看它究竟帮了什么
现在可以回答标题里的问题了。
从回答问题到帮你做事，多出来的是一段能够与外部信息和实际操作发生联系的过程：围绕目标选择动作，由程序执行，把结果带回下一轮判断，直到交付，或在条件不足时暂停。
这段过程里，模型负责的判断、工具实际完成的操作，以及应用保存和控制的信息，都有各自的作用。任何一部分出问题，都可能让一个听起来合理的计划停在半路。
以后看一个 Agent 演示，可以试着改变其中一个条件：查询失败了怎么办？材料互相矛盾怎么办？用户中途补充要求，又会怎样继续？
能解释这些变化，才说明自己开始理解它怎样工作。也更容易判断：眼前这个产品接过了哪些事情，哪些仍然需要自己处理。
回到周报例子，真正值得期待的帮助，是让材料得到整理、疑点被找出来、能核实的得到核实。最终交回来的草稿，应当让人有依据继续工作。做到这里，即使仍有一项需要确认，也比掩盖不确定性更有用。
理解了这套机制，开发 Agent 也就有了清楚的学习目标：怎样让模型获得合适的信息，怎样连接有效的动作，以及怎样让人知道事情走到了哪里。
下一篇，我们继续讨论《AI 工具已经这么多，为什么还要做自己的工作台？》，看看这些能力为什么还需要被组织成一个适合自己使用的地方。