侯君璠，AI架构陪跑师，清华大学工程管理硕士（MEM），企业架构研究会发起人，国内大型央企单位技术总监、解决方案专家。20余年工作经验，曾任美国某大型科技公司-M中国区首席架构师，国内某大型险资技术总监、某大型科技咨询公司副总裁。深耕于企业架构、人工智能研究与落地方案，以及先进工程项目管理和企业数字化转型等领域。

八、Memory 的本质：管理状态，而不是记得更多

Memory 也是一个非常容易被误解的模块。很多人一说记忆，就想到长期偏好、用户画像、历史对话和个性化体验。

这些当然重要，但不是 Memory 在 Agent 工程里的全部意义。在工程系统里，Memory 首先是状态管理问题。

任务执行到哪一步了？用户刚刚确认了哪个方案？哪个文件是原始版本？哪个结果已经废弃？哪个工具调用失败过？哪些内容不能被模型改写？哪些偏好只对本次任务有效？这些都是状态。

没有状态管理，Agent 在多轮任务里就会丢信息、重复工作、前后矛盾。

但 Memory 不能滥用。因为记忆不是只会带来智能，也会带来污染。

临时偏好如果被写进长期记忆，会污染未来任务；过期信息如果没有清理，会干扰当前判断；模型总结出来的记忆如果不准确，会在后续反复放大错误。

所以 Memory 的核心不是“记住”，而是“分层”。当前步骤的信息，放运行态；当前任务的信息，放任务状态；当前会话的信息，放会话记忆；长期稳定的信息，才进入长期记忆；外部知识不要硬塞进记忆，而是通过检索按需读取。

【企业架构研究会在4月份发布了智能架构的研究报告，如有希望获取的，请留言：“获取资料”并添加文章最下方的联系人，我们恭候各位到来一同研讨中国的企业IT架构应该怎么做】

用户上传了一份代码、一份合同、一段视频脚本，不要让模型在上下文里反复复制全文。应该把它存到文件系统、对象存储或者数据库里，再传递文件 ID、段落 ID 或版本号。需要时，再由工具读取原文。

这样做有两个好处：第一，节省 Token；第二，避免模型在复制过程中改坏内容。尤其是代码、合同、财务数据、配置文件这类内容，模型“顺手优化”一下，可能就是事故。

成熟 Agent 的 Memory，不是一个浪漫的长期记忆库。它是一套严肃的状态管理和引用传递机制。

九、Trace 和 Eval，是 Agent 从 Demo 走向生产的分水岭

Agent 原型很容易做。让模型接几个工具，跑几个演示，看起来就已经很智能。但 Agent 上线很难。

难点不在于它能不能偶尔成功，而在于它失败之后能不能定位，修改之后能不能验证，版本变化之后能不能回归。

没有 Trace 的 Agent，基本无法调试。一次失败发生后，你必须知道：用户输入是什么，系统提示词是什么，模型看到了哪些上下文，它为什么选择这个工具，工具参数是什么，工具返回是什么，哪一步开始偏离目标，最终答案引用了哪些中间结果，Token 和延迟消耗在哪里。

这些信息如果没有记录，团队只能凭感觉调 Prompt。这不是工程，这是玄学。

Eval 也是一样。很多 Agent 项目一开始靠人工体验判断效果。今天感觉不错，明天感觉变差，换个模型好像更好，改一句 Prompt 好像又不稳定。

但没有评估集，就无法判断系统到底有没有进步。成熟 Agent 必须有真实任务样本。每次改 Prompt、换模型、调工具、改上下文策略，都要跑回归。

看成功率，看成本，看延迟，看错误类型，看是否引入新的失败模式。Trace 解决“为什么错”。Eval 解决“有没有变好”。

没有这两件事，Agent 最多是一个能演示的系统，还不能算真正的工程系统。

十、一个更合理的 Agent 演进路径

现在可以把整条逻辑串起来。AI Agent 不应该从复杂架构开始。它应该沿着任务不确定性的增加，逐步演进。

·第一阶段，任务只是语义转换，用 LLM Call。重点是 Prompt、示例、输出格式和模型选择。

·第二阶段，任务有多个步骤，但流程固定，用 Workflow。重点是流程编排、异常处理、重试和结果校验。

·第三阶段，任务需要动态决策，引入 Agent Loop。重点是模型如何观察状态、选择行动、调用工具、接收反馈。

·第四阶段，工具增多，引入工具治理。重点不是继续加工具，而是压缩工具选择空间，降低误用概率。

·第五阶段，上下文开始变脏，引入 Context Engineering。重点是控制模型每一步看到什么，而不是把所有信息都塞进去。

·第六阶段，任务边界明显分化，引入 Sub-Agent。重点是上下文隔离，而不是角色命名。

·第七阶段，任务跨步骤、跨轮次，引入 Memory 和 State。重点是状态管理、引用传递和长期信息治理。

·第八阶段，系统准备上线，引入 Trace、Eval 和 Guardrail。重点是可观测、可回归、可审计、可控制。

图 5：一个更合理的 Agent 演进路径

结语：Agent 架构真正考验的，是工程判断力

做 AI Agent，真正难的不是会不会用新框架，也不是会不会写复杂 Prompt，更不是会不会画一张多智能体架构图。真正难的是判断。

判断一个任务是否需要 Agent。判断一个流程是否应该交给 Workflow。判断一个工具是否真的必要。判断一段上下文是否应该进入模型。判断一个偏好是否值得长期记忆。判断一个失败是否需要架构调整。判断一个高级模块是不是来得太早。

Agent 架构的成熟，不是看它有多少模块，而是看每个模块是否有清晰的工程理由。

·Planner 必须对应路径不确定。

·Memory 必须对应状态管理问题。

·Sub-Agent 必须对应上下文隔离问题。

·Tool Router 必须对应工具选择问题。

·Trace 和 Eval 必须对应生产调试和质量回归问题。

如果一个模块说不清楚自己解决什么失败，它就不该存在。

所以，做 Agent 最重要的不是把架构图画满，而是保持克制。一次调用能解决，就不要做 Workflow；Workflow 能解决，就不要做 Agent；单 Agent 能解决，就不要拆多 Agent；短期状态能解决，就不要做长期记忆；日志能定位问题之前，不要空谈智能自治。

AI Agent 的架构不是功能堆栈。它是一套围绕不确定性建立起来的控制系统。

真正专业的 Agent 设计，不是看起来最优雅的那一个。而是在每一个阶段，都只增加那个刚好必要的复杂度。