AI 学习 | Agent 架构的演进

让 AI 回答“有哪些好用的文档协作工具”，和让它“比较三款产品，核实价格和使用限制，整理成一份有出处的报告”，看起来只差一句话，背后需要的能力却很不一样。

前一个问题，给出一段回答就可以结束。后一个任务，需要查资料、判断哪些信息可信、处理互相矛盾的说法，还要检查报告有没有遗漏。做到一半被打断，下次最好能接着做。

回看这几年，Agent 架构的变化有一条很清楚的线索：我们希望交给 AI 的工作越来越完整，原本需要人补上的信息、操作和检查，也就逐渐被写进了系统。

#01Prompt：从写好提示词开始

在聊天式的用法里，我们最容易调整的是提示词（Prompt）。目标怎么描述，背景交代多少，要不要给一个示例，都会影响回答。这些围绕指令和示例的设计，通常叫作提示词工程（Prompt Engineering）。

比如，“比较一下这三款产品”就比较模糊。如果补充“五人团队使用，主要关注共同编辑、权限管理和总费用，价格以官网为准”，模型就更容易理解该查什么、怎样比较。

但即使要求说得很清楚，查官网、找价格、把新资料补进对话，仍然可能要你来做。AI 负责回答，你负责推动整个过程。

一个重要的变化，是让模型参与决定下一步操作。2022 年提出的 ReAct 方法，就是这条路线上的代表性工作：模型交替进行推理和行动，通过外部工具取得新信息，再据此调整下一步。

放进查资料的任务里，它可以先搜索官网，发现价格分月付和年付，再打开详细说明；发现某项功能只有高价套餐提供，就继续核对套餐差异。工具返回的结果，会影响它接下来做什么。

这样就形成了一个基本的工作循环：判断下一步、调用工具、读取结果，再决定继续还是结束。

不过，能自己查资料以后，另一个问题很快出现了：查到的东西越来越多，它还能一直记得我们最初要什么吗？

#02Context：让模型看到合适的信息

一份产品对比可能涉及几十个网页。里面既有最新价格，也有过期的测评；既有关键限制，也有大段与任务无关的介绍。如果全部塞进对话，模型需要处理的内容会迅速增加。

模型在当前这一步能看到的指令、历史消息、工具说明和查询结果，合起来叫作上下文（Context）。模型能接收的内容有长度限制；即使没有超过限制，材料过多、重复或互相矛盾，也可能让它漏掉重要条件。

因此，工程师要处理的事情从“这句话怎么写”，扩展到了“这一步应该给它哪些信息”。这就是上下文工程（Context Engineering）关注的问题。

查价格时，需要保留团队人数、计费周期和刚找到的套餐说明；检查权限功能时，再读取对应的帮助文档。较长的网页可以保存在外部，需要时重新打开，已经确认的事实则整理进简短的记录。

这也解释了为什么把所有聊天记录都留下来，并不等于做好了记忆。存下来的内容，需要在合适的时候被找出来，模型才能用上。

左侧围绕提示词组织一次回答；右侧从文档、工具和记忆中筛选信息，并接收工具反馈。来源：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

前面提到的搜索、资料整理和进度记录，都依赖模型之外的软件。任务越长，这部分软件要承担的事情也越多。

#03Harness：给模型一个能够完成工作的环境

假设模型已经判断出某个报价过期了，它需要重新打开网页；报告写完了，它需要保存文件；查询失败了，它需要知道是页面不存在，还是暂时无法访问。

这些事情都要依靠模型之外的软件来完成。围绕模型组织工具调用、上下文、任务状态和执行规则的这套运行系统，通常被称为 Agent Harness。设计和改进这套系统，就是 Harness Engineering。

还是这份报告。搜索工具负责取得资料，文件工具负责保存内容，任务记录负责留下进度。遇到需要登录的页面，系统要明确返回访问限制；如果任务涉及开通试用或付费，执行环节还要落实相应的授权要求。

模型负责判断该做什么，运行系统负责让操作实际发生，并把结果带回来。工具是否好用、错误是否清楚、操作后能不能看到真实结果，都会影响最后的交付。

模型居中，周围的系统负责提供上下文、控制流程、执行行动、保存记录和检查结果。来源：https://www.langchain.com/blog/the-anatomy-of-an-agent-harness

任务再长一些，还会遇到交接问题。上一轮已经核对过两款产品，下一轮应该知道剩哪一款；文件已经保存成功，恢复时也要能确认当前版本。如果只留下“继续完成报告”这句话，接手时就得重新查找进度。

在长时间运行的 Agent 实践中，一种有效的做法是保存任务清单、已完成的工作和验证结果，让新的会话据此接手。Anthropic 在 2025 年底分享的编程 Agent 实验，就用功能清单和进度文件处理了这种跨会话交接。

任务记录还需要放在能持久保存的地方。运行进程退出后，下次恢复才能重新读取它们，核对已经发生的操作，再继续剩余工作。

至此，Agent 有了完成较长任务的基础。不过，报告写出来以后，由谁判断它是否达到了要求？

#04Loop：让系统根据结果继续推进

“报告已完成”是模型给出的结论。价格有没有核实、三款产品是否按同一种计费方式比较、引用能不能支持正文中的判断，还需要逐项检查。

前面提到的执行循环（Agent loop），让模型根据工具结果决定下一步行动。要判断产出是否合格，可以在它外面加一层验证循环（Verification loop）：检查结果，发现问题就带着反馈返回修改。

比如，程序可以检查三款产品的必要字段是否齐全、费用计算是否正确；事实与来源是否一致，可以安排另一轮核对。检查发现价格缺少计费周期，就把具体问题交回执行环节，补查后再检查。对来源冲突、难以判断的内容，则保留疑问交给人处理。

验证循环示例（Level 2）：在执行循环外增加结果检查，未通过就带着反馈继续修改。来源：https://www.langchain.com/blog/the-art-of-loop-engineering

如果这份报告需要每周更新，就要在执行和验证之外，接入事件驱动循环（Event-driven loop）。到了约定时间，系统便启动新一轮工作，读取上次记录、补查变化，再检查和保存结果。收到新的资料，也可以成为启动条件。

报告持续更新后，运行记录还可以用来改进系统。假如它经常混淆月付价和年付价，可以让系统分析这些记录，调整提示、工具配置或检查规则，再用已有案例评测效果，保留有效的改动。这就是改进循环（Hill-climbing loop）：改动会用于后续任务，让系统少犯同样的错误。评测（Evaluation）既要确认问题得到改善，也要检查原本做得好的任务有没有受到影响。

这些不同范围的循环如何设计、如何配合，是循环工程（Loop Engineering）关注的问题。

一个能持续工作的 Agent，需要明确什么算完成，也需要明确什么情况下必须停下来。 找不到可靠资料时不能无限搜索，同一个错误反复出现时也不该一直重试。尝试次数、时间和费用的边界，都应该进入系统的判断。

检查和改进逐渐接进来以后，任务也不再总是一条直线。有些资料可以分头查，有些结论却必须等前面的工作做完。

#05Graph：把分支、依赖和协作组织起来

比较三款产品，资料收集可以同时进行。但在分头查之前，需要先确定共同口径：都按五人团队计算，采用同一种计费周期，记录满足需求的套餐。否则，三个结果即使各自没错，放在一起也无法比较。

可以把这样的执行过程表示成一张图：每项工作是一个节点，节点之间的连线说明下一步可以去哪里，任务状态记录已经得到的信息和当前进度。这种用图组织执行过程的方法，通常叫作图式编排。

确定比较口径后，流程分成三个资料收集分支；等资料齐全，再汇总和检查。某款产品的信息缺失，就返回对应分支补查；仍然无法确认，就在报告中标明。这些依赖、并行和返工路径，都可以用节点和连线表示。

图中将 GitHub、Notion、Slack 三路检索并行展开，再汇总成报告。来源：https://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph

节点不一定都是 Agent。费用加总可以交给普通程序，资料收集可以交给能自主搜索的 Agent，最终确认也可以留给人。需要判断的地方让模型判断，已经明确的规则则直接执行。

当任务适合分头探索时，还可以让多个 Agent 分别负责一部分工作。此时除了分工，也要设计信息怎样交接：每个执行者拿到哪些背景，返回哪些证据，由谁检查和汇总。如果分得太碎，交接和重复查找的成本也会增加。

图式编排出现得很早。2024 年发布的 LangGraph，就已经用状态、节点和连线组织带循环的 Agent 程序。 近来图工程（Graph Engineering）的讨论，重新强调了这些执行关系的设计：一个节点内部可以运行完整的 Agent 循环，节点之间则安排分工、依赖和返工路径。

#06回到我们要完成的事

这些设计一直在交叉发展，也常常出现在同一个系统里。用一个循环就能完成的工作，没有必要拆成一群 Agent；流程比较固定时，把步骤写清楚就很有用；需要边查边调整方向时，则要给模型留下判断空间。

理解这段演进，对使用者也有一个直接的帮助。下次 Agent 没把事情做好，可以先看它卡在哪里：要求没说清，资料没拿到，工具无法执行，还是做错以后没有被检查出来？找到具体缺口，才知道该补充一句说明、一份资料，还是改一段工作流程。