一个让很多团队头痛的事实：Demo 惊艳，上线就崩。
AI 应用开发的第一波浪潮里，大家都在卷 Prompt。但如今 prompt 写得好不好，不是决定性因素，架构才是！
最近读了一篇讲 Goal-Oriented Agents 的文章（Mamdouh Alenezi，arXiv 2026），里面有个观点很有意思：大多数 AI Agent 项目失败，不是模型不够强，是架构设计从一开始就有问题。
为什么单 Pass 模型注定失败
早期 LLM 应用是函数式的：Prompt 进，Answer 出。任务能塞进一次调用、一个上下文窗口，就能运行。但一旦涉及多步推理、重试机制、或跨类型工作的协调，单 Pass 模式立刻爆掉。
以客服 Agent 为例。Demo 阶段，用户扔一个问题，Agent 从知识库找个答案。但切到真实工作流，例如 200 张工单，要查订单历史、要核对退货政策、要交叉引用保修条款、要起草个性化解决方案。Agent 在第 50 张工单的时候，就开始混淆客户信息，退货政策套用也会错误，发了一堆自信但离谱的解决方案。
根源不是 Prompt 不够好，是 Agent 被做成了 Chain（链条）！一条从输入到输出的直线，无记忆、无适应、无重试能力。Chain 是无状态的管道，处理一次就丢掉所有中间状态。它不知道前面做了什么，遇到错误不能改道，把每个请求都当作第一次认识这个世界。
Goal-Oriented Agent（目标导向 Agent）的思路完全不同。它是一个有状态的系统，环形运转而非直线穿过。
Plan → Execute → Observe → Update → Repeat
核心是这个迭代推理循环。Agent 先把目标拆成任务列表，执行第一步，观察结果（成了吗？有意外吗？），根据学到的东西更新计划，然后再进入下一步。直到目标达成。
没有这个循环，Agent 会试图在一次调用里处理 200 张工单，从第 50 张开始出错。有这个循环，每一步的输出都扎根于前一步的结果，而不是凭空生成。
四层架构：生产级 Agent 的收敛方向
工程团队把单 Pass Agent 重构为可扩展系统时，最终的架构形态出奇一致。无论用哪个框架，基本用的都是四层结构：
第一层：Planning（规划）
目标是“把所有工单都处理好”，但“怎么处理”不是一开始就确定的。Planning 层做的是把意图和行动分离。先搞清楚要做什么，再决定怎么做。
Agent 创建任务列表：工单按类型分类，查询客户账户，核对订单历史，匹配相关政策，起草解决方案，标记需要升级的案例。这个列表不是固定的。当 Agent 发现某类工单出现了新的情况，会把新的步骤加进去。当它意识到几个工单来自同一客户且问题相关，会合并处理。
没有 Planning 层，Agent 在复杂任务上会跑偏，模型丢掉对原始需求的跟踪，或者过早锁定一个后来被证明错误的方案。Planning 层让 Agent 的意图变得可见且可修改。
第二层：Delegation（委托）
让一个模型同时做账户查询、退货政策解读、客户回复起草，会把单一上下文塞满不兼容的角色，三件事的质量一起下降。
Goal-Oriented Agent 通过委托解决这个问题。一个 Orchestrator（主 Agent）持有总体目标，把有边界的任务分配给专门的子 Agent。一个处理账户查询和订单历史，一个解读政策并判断适用性，第三个起草给客户的回复。
每个子 Agent 在独立隔离的上下文中运行，只专注自己的任务。只有最终输出流回 Orchestrator。这让主流程保持干净，每个子任务保持专注。
这里有个细节值得注意：子 Agent 并行运行时，如果不共享上下文，可能做出互相矛盾的决策。对于需要紧密协调的任务，顺序执行反而比并行化更可靠。
第三层：Persistence（持久化）
处理第 200 张工单时，Agent 需要记得第 1 张是怎么处理的。但没有任何模型的上下文窗口能同时装下 200 个客户的账户信息、订单历史、政策决策、解决方案草稿。
Persistence 层解决这个问题的方式是给 Agent 外接记忆。每处理完一张工单，Agent 把结果写入外部存储：客户明细、订单查询记录、政策判断、方案草稿。下一次需要用到之前的结果时，不是把所有历史塞进上下文，而是只读取相关的部分。
这让工作的复杂度与模型的记忆能力解耦。任务可以扩展到 200 张、2000 张工单，而不会让上下文窗口成为瓶颈。在客服场景里，Agent 处理 200 张工单和處理 1 张工单的准确率相同，因为每个结果都存在外部而不是被压缩进越来越满的 prompt。
第四层：Synthesis（综合）
处理完所有工单后，最终输出不是 200 封各自为战的回复邮件，而是一个已解决的队列！政策应用一致，需要升级的案例被标记，有换班总结报告。
这是 Synthesis 层：合并并行子结果为一个统一交付物。Map 阶段，各子 Agent 独立完成有边界的任务，并行或隔离运行，产生各自的输出。Reduce 阶段，Orchestrator 读取所有存储的子输出，解决相互间的矛盾，识别跨工单的模式，最终组装出完整的队列和摘要报告。
这个 Map-Reduce 模式在数据处理领域很常见，直接迁移到 Agent 工作流同样有效。最终输出质量取决于四层是否协同工作？Planning 确保没有遗漏，Delegation 确保每块工作被正确处理，Persistence 确保没有遗忘，Synthesis 确保各部分形成一个有机整体。
这场迁移还没结束
从 Chain 到 Loop，从单 Pass 到四层架构，Prompt 工程师的角色在悄然改变。
不再只是“怎么问”，而是“怎么组织”。系统设计能力、任务分解能力、结果整合能力！这些以前属于软件架构师的能力，正在变成 AI Agent 开发者的核心技能。
Prompt 写得好是门槛，架构设计得好才是护城河。
