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

很多 AI Agent 项目，表面上是输给了模型能力，实际上是输给了架构冲动。

系统还没跑稳，就开始加 Planner；任务还没复杂到不可控，就开始拆 Sub-Agent；上下文还没有明显污染，就开始做上下文隔离；用户偏好还没稳定，就开始设计长期记忆；连失败样本都还没积累多少，就急着上 Trace、Eval、Guardrail。

看起来很专业。架构图也确实越来越漂亮。

但一跑起来，结果往往并不理想。Token 消耗上去了，响应速度下来了；原本一次调用就能完成的任务，被拆成了好几个步骤；原本容易定位的问题，被 Planner、Memory、Tool Router、Sub-Agent 一层层包住，最后连失败到底发生在哪里都说不清。

这不是某一个团队的问题，而是当前 AI Agent 落地里非常普遍的误区。

很多人把成熟 Agent 系统的“最终形态”，误当成了新项目的“初始架构”。但真正的 Agent 架构，不是这样长出来的。

图 1：简单任务与过度架构的复杂度差异

一、一次架构升级，让我们重新理解了 Agent

真正让我重新思考 Agent 架构的，不是一篇论文，也不是某个开源框架，而是一次并不成功的系统升级。

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

当时我们在做一个视频 AI Agent。最早的版本很简单。用户输入视频脚本、创作诉求或者修改意见，系统根据任务生成标题、封面方向、剪辑建议和视觉方案。部分能力会调用工具，但整体链路不长，问题也比较容易定位。

它算不上优雅，但能跑。

后来，我们开始参考一些成熟 Agent 系统的设计思路。任务规划、工具路由、上下文隔离、记忆模块、子任务执行器，这些能力看起来都很有价值。于是，我们做了一次比较彻底的架构升级。

系统提示词重写了，执行链路重新拆分了，上下文重新分层了，记忆模块加进来了，工具调用也被包装成了更完整的调度体系。

从架构图上看，系统明显更像一个“真正的 Agent”了。但真实运行结果没有变好。

相同任务下，Token 消耗明显上升；一些原本稳定的简单任务，反而开始出现波动；执行链路拉长之后，调试难度也明显增加。

一个任务失败了，很难马上判断问题出在哪里。是用户意图理解错了？是 Planner 把任务拆错了？是工具选错了？是上下文给多了？是记忆取出了旧信息？还是某个执行模块没有拿到关键约束？

每个模块单独看都合理。但组合在一起之后，系统的不确定性反而被放大了。

二、传统软件的架构直觉，在 Agent 里会失效

做传统软件，前置架构设计通常是好事。服务怎么拆、接口怎么定义、数据怎么流转、异常怎么处理、部署怎么扩展，这些设计越清晰，系统越稳定，后期维护成本也越低。

原因很简单：传统软件大多是确定性系统。同样的输入，经过同样的逻辑，通常会得到同样的输出。只要边界定义清楚，模块职责稳定，系统行为就是可预测的。

但 AI Agent 不一样。Agent 的核心执行体不是一段确定性代码，而是大模型。

大模型会根据上下文做判断。它会判断用户想要什么，判断信息是否足够，判断要不要调用工具，判断下一步怎么做，判断当前结果是否可以交付。它有推理能力，也有漂移风险。

这意味着，一旦你把决策权交给模型，系统就不再是传统意义上的确定性流程，而变成了一个带有概率性、上下文敏感性和行为波动的决策系统。

这时候，架构的目标就变了。传统软件架构，核心是拆分复杂度；Agent 架构，核心是控制不确定性。

如果没有理解这一点，就很容易把 Agent 架构做成模块堆叠：看到别人有 Planner，自己也加 Planner；看到别人有 Memory，自己也做 Memory；看到别人有 Sub-Agent，自己也拆 Sub-Agent。

但问题是：你的系统真的出现了路径不确定吗？真的出现了状态丢失吗？真的出现了上下文污染吗？真的出现了多工具选择失控吗？真的到了必须用评估体系做回归的阶段吗？

如果这些问题还没有出现，或者还没有被验证，就提前把模块加进去，复杂度就不是资产，而是负债。

三、先分清三件事：LLM Call、Workflow 和 Agent

很多 Agent 项目一开始就走偏，是因为没有分清三件事：LLM Call、Workflow 和 Agent。

这三者都可能调用大模型，但它们解决的问题完全不同。

一次 LLM 调用，解决的是语义转换问题

有些任务，本质上只是一次语义转换。比如给文章起标题，把会议纪要压缩成摘要，从合同里提取关键字段，根据一句描述生成封面创意，把一段文字改成更正式的表达。

这类任务的特点很清楚：输入明确、目标明确、不需要外部状态、不需要中途决策，也不需要模型自己规划下一步。它的难点主要在模型理解和生成。

所以这类任务最应该优化的是 Prompt、示例、输出格式和模型选择，而不是 Agent 框架。

如果一个标题生成任务，本来一次调用就能完成，却非要让模型先规划、再执行、再反思，结果大概率不是更智能，而是更慢、更贵、更不稳定。

固定流程，解决的是确定性编排问题

再复杂一点，有些任务不止一步。比如视频一键剪辑：先转字幕，再识别无效片段，再生成剪辑点，再调用剪辑工具，最后导出视频。

这个过程确实有多个步骤，也可能用到模型和工具。但它未必是 Agent。因为它的流程是可以提前定义的。

第一步做什么，第二步做什么，失败怎么重试，输出怎么校验，这些都可以被写进固定流程。

这种任务更适合 Workflow。Workflow 的价值不是让系统自由思考，而是让系统稳定执行。

它适合那些流程明确、路径固定、用户不需要中途参与的任务。很多企业场景其实都属于这一类：报表生成、数据清洗、合同初审、素材处理、工单流转、审批前置检查。它们需要大模型，但不一定需要 Agent。

真正的 Agent，解决的是动态决策问题

真正进入 Agent 的，是另一类任务。目标不够明确，路径无法提前写死，用户偏好需要反复澄清，工具选择依赖当前上下文，中间结果会影响下一步行动，最终结果需要多轮反馈才能收敛。

比如用户说：帮我把这个视频改得更有高级感。

这句话没法直接写成固定流程。高级感到底是什么？是画面更克制，还是节奏更慢？是色调更冷，还是字幕更干净？是镜头更像商业广告，还是音乐更有质感？

这类任务没有一个稳定的标准答案。系统必须先理解用户意图，再提出方向，再根据反馈调整方案，必要时调用工具，还要在多个可能路径之间做选择。

这时候，Agent 才真正有价值。因为它解决的不是“生成内容”本身，而是“在不确定任务中持续做决策”。

图 2：LLM Call / Workflow / Agent 的选择判断

【持续未完，敬请期待】