1. 被“Agent”框住的那两年，我到底在做什么

2023年春天，我第一次在项目里认真引入 Agent 这个概念。当时团队接了一个内部知识问答的需求，用户提问，系统检索文档，然后让大模型基于检索结果生成回答。听起来很标准的 RAG 流程，但客户加了一个要求：回答里如果涉及操作步骤，要能自动调用内部工单系统创建任务。于是我们很自然地走上了 Agent 这条路——给模型挂几个工具，让它自己决定什么时候检索、什么时候调接口、什么时候直接回答。

那套系统上线后跑了大概半年，我前前后后改了十几版 prompt，调了无数次工具描述，加了各种兜底逻辑。直到有一天复盘，我突然意识到一个问题：我们花了大量精力在“让模型学会调用工具”这件事上，但真正让用户满意的那些回答，绝大多数根本不需要工具调用。用户要的是一个准确的、有出处的、格式清晰的答案，而不是一个会自己决定去查工单的“智能体”。

这个认知让我开始重新审视 Agent 这个范式。不是说它没用，而是说当我们把“Agent”当成 AI 应用的默认形态时，很多本来更简单、更可控、更高效的方案就被我们主动忽略了。这篇文章想聊的就是这件事：Agent 范式到底限制了我们哪些想象力，以及在它之外还有哪些值得认真考虑的路子。

如果你正在做 AI 应用开发，不管你是刚入门的程序员，还是已经带过几个项目的技术负责人，只要你曾经在“要不要上 Agent”这个问题上纠结过，这篇内容应该能给你一些不一样的视角。我会从范式本身的边界讲起，拆解几个被 Agent 思维遮蔽的方案，再结合我实际踩过的坑，给出一些可以直接参考的判断标准和落地方法。

2. Agent 范式的边界：它擅长什么，又不擅长什么

2.1 先搞清楚 Agent 到底在解决什么问题

很多人对 Agent 的理解停留在“会调用工具的大模型”这个层面，这个理解不算错，但太窄了。Agent 范式真正解决的问题是：当任务无法用一次模型调用完成时，如何让模型在多轮交互中自主推进。

举个具体的例子。用户说“帮我查一下上个月华东区的销售数据，如果环比下降超过10%就发一封预警邮件给区域负责人”。这个任务里有条件判断、有数据查询、有外部动作，单次模型调用搞不定，因为模型不知道上个月的数据是什么，也不知道负责人的邮箱。这时候 Agent 的价值就体现出来了：它可以先调数据接口，拿到结果后判断是否满足条件，满足的话再调邮件接口。

所以 Agent 的核心能力其实是三件事：任务分解、工具编排、状态管理。任务分解是把模糊需求拆成可执行的步骤，工具编排是决定每一步用哪个工具、传什么参数，状态管理是记住前面步骤的结果并在后续步骤中使用。

这三件事听起来很合理，但问题在于，它们都是“模型自主决策”的。模型自主决策意味着不确定性，不确定性意味着你需要花大量精力去做约束、做兜底、做测试。而很多实际业务场景，根本不需要这种自主性。

2.2 自主性的代价：为什么 Agent 项目总是“demo 很惊艳，上线很痛苦”

我见过太多 Agent 项目死在从 demo 到上线的路上。Demo 阶段，你给模型几个工具，它偶尔能跑通一个复杂流程，演示效果很好。但一旦要上线，问题就来了。

第一个问题是路径不可控。同样的输入，模型这次决定先查数据库再调接口，下次可能反过来，甚至可能跳过某一步直接编一个答案。你没法像传统程序那样保证“输入 A 必然走路径 B”。我试过用 prompt 里写死步骤来约束，但模型有时候会“自作主张”地优化流程，结果反而出错。

第二个问题是错误会累积。Agent 是多轮决策，每一步都可能出错。第一步查错了数据，第二步基于错误数据做判断，第三步基于错误判断发邮件，最后整个链路崩掉。而且因为中间步骤是模型自主决定的，你很难定位到底是哪一步出了问题。

第三个问题是测试成本极高。传统函数你可以写单元测试，输入固定输出固定。Agent 的测试要覆盖各种可能的决策路径，而且模型本身还有随机性，同一个输入跑十次可能有三种不同的执行路径。我做过一个统计，一个包含五个工具的 Agent，理论上可能的执行路径超过两百种，实际测试中能覆盖到的不到三成。

注意：如果你的业务场景对确定性要求很高，比如金融交易、医疗建议、法律文书生成，Agent 的自主性带来的风险往往大于收益。这时候应该优先考虑确定性更强的方案。

2.3 被忽略的中间地带：从“全自主”到“零自主”的连续光谱

Agent 范式的最大问题不是它本身不好，而是它让我们把注意力都放在了“全自主”这一端，忽略了中间大片的连续光谱。

实际上，AI 应用的自主性可以分成好几个层级。最左边是零自主，就是传统的“输入-模型-输出”模式，模型只负责生成内容，不调用任何工具。往右一点是固定流程加模型节点，比如你先检索再生成，流程是写死的，模型只在特定节点做特定的事。再往右是有限分支，模型可以在预设的几个分支里做选择，但不能自由发挥。再往右才是 Agent，模型自主决定步骤和工具。

我后来复盘那个知识问答项目，发现最稳定的方案其实是“固定流程加模型节点”：先检索，再让模型基于检索结果生成回答，如果回答里包含操作步骤，再用一个独立的模型调用去判断是否需要创建工单。整个流程是确定的，模型只在两个明确的节点做两件明确的事。这个方案比 Agent 方案少了大概百分之七十的代码量，稳定性却高了一个数量级。

3. 跳出 Agent 思维后，我重新审视的四个方案

3.1 方案一：工作流编排，把“智能”留给模型，把“控制”留给自己

工作流编排的核心思路是：流程由人定义，模型只在流程中的特定节点做特定的事。这听起来好像退回了传统软件，但实际上它结合了模型的生成能力和传统程序的确定性。

具体怎么做？你可以用代码或者配置来定义一个有向无环图，每个节点是一个操作，比如“调用检索接口”“调用模型生成”“调用外部 API”。节点之间的连线是固定的，但节点内部的逻辑可以包含模型调用。

举个例子。一个合同审核的 AI 应用，流程可以这样设计：第一步，解析合同文本，提取关键条款；第二步，对每个关键条款调用模型判断风险等级；第三步，汇总风险等级生成审核报告；第四步，如果风险等级超过阈值，调用通知接口。整个流程是固定的，模型只在第二步和第三步做判断和生成。

这种方案的好处是可测试、可监控、可回滚。每个节点都可以单独测试，每个节点的输入输出都可以记录，出问题可以快速定位到具体节点。而且因为流程固定，你可以精确控制每一步的耗时和成本。

我后来用这个思路重构了那个知识问答项目，把整个流程拆成检索、生成、判断、通知四个节点，用代码串起来。上线后稳定性大幅提升，而且因为每个节点都可以单独优化，整体效果反而比 Agent 方案更好。

3.2 方案二：多模型协作，让不同的模型做不同的事

Agent 范式通常是一个模型包打天下，所有决策都由同一个模型做。但实际上，不同模型有不同擅长的事。有的模型擅长理解复杂指令，有的模型擅长生成结构化输出，有的模型擅长做分类判断。

多模型协作的思路是：把任务拆开，每个子任务用最合适的模型。比如一个客服场景，用户输入先经过一个轻量模型做意图分类，如果是咨询类问题走检索加生成流程，如果是投诉类问题走另一个流程，如果是技术问题走第三个流程。每个流程里用的模型也可以不同。

这种方案的好处是成本可控、效果可调。轻量模型便宜且快，适合做分类和路由；大模型贵但效果好，适合做最终生成。你可以根据每个环节的重要性来分配模型资源。

我试过一个方案，用一个小模型做意图识别和参数提取，用一个大模型做最终回答生成。整体成本比全用大模型低了大概百分之六十，效果几乎没有下降。因为意图识别和参数提取这类任务，小模型经过少量微调就能做得很好，不需要大模型的通用能力。

3.3 方案三：模板加填充，把生成任务变成填空任务

这个方案可能听起来最不“AI”，但在很多场景下效果最好。核心思路是：不要让模型自由生成，而是给它一个模板，让它只填充模板里的变量。

比如生成周报，你可以给模型一个固定的结构：本周完成事项、下周计划、风险与问题。模型只需要往每个部分里填内容，不需要自己决定周报的结构。再比如生成产品描述，你可以给一个模板：产品名称、核心卖点、适用场景、价格。模型只负责提取和填充。

这种方案的好处是输出稳定、格式可控。你不用担心模型这次生成三段、下次生成五段，也不用担心它突然加一个你不需要的部分。而且因为模板是固定的，你可以针对每个字段单独优化 prompt，效果往往比让模型自由生成更好。

我做过一个对比测试，同一个产品描述生成任务，自由生成方案和模板填充方案各跑一百次。自由生成方案有大概百分之十五的输出格式不符合要求，需要人工修正；模板填充方案只有百分之三不符合要求，而且不符合的原因基本都是内容质量问题，不是格式问题。

3.4 方案四：规则引擎加模型兜底，能用规则的地方不用模型

这个方案的核心思路是：能用确定性规则解决的问题，就不要用模型。模型只用来处理规则覆盖不到的边缘情况。

比如一个工单分类系统，你可以先写一堆关键词规则，命中规则的直接分类，没命中的再交给模型判断。实际运行中，大概百分之七十的工单都能被规则覆盖，只有百分之三十需要模型介入。这样既保证了大部分情况的确定性，又利用了模型的泛化能力处理长尾。

这种方案的好处是成本低、响应快、可解释。规则匹配是毫秒级的，模型调用是秒级的。而且规则命中的结果你可以直接解释给用户看，模型判断的结果往往需要额外的解释层。

我后来在多个项目里用了这个思路，效果都很好。关键是要定期分析模型兜底的那部分数据，看看有没有新的模式可以沉淀成规则。这样规则覆盖率会越来越高，模型调用越来越少，整体成本和延迟都会持续下降。

4. 实操：怎么判断一个需求该不该上 Agent

4.1 三个问题帮你快速做判断

每次有人问我“这个需求要不要用 Agent”，我都会让他先回答三个问题。

第一个问题：任务的步骤是否固定？如果步骤固定，比如“先查数据再生成报告”，那就不需要 Agent，用工作流编排就行。如果步骤不固定，比如“根据用户问题决定查什么数据、怎么查、查完做什么”，那才需要考虑 Agent。

第二个问题：错误的代价有多大？如果错误代价高，比如涉及资金、法律、医疗，那就尽量用确定性方案，Agent 的自主性带来的风险可能无法接受。如果错误代价低，比如生成一个草稿让用户修改，那 Agent 的灵活性优势就值得考虑。

第三个问题：你能接受多高的不确定性？Agent 的输出是不确定的，同样的输入可能走不同的路径。如果你能接受这种不确定性，并且有相应的兜底和人工审核机制，那可以考虑 Agent。如果你需要百分之百的确定性，那就不要用 Agent。

这三个问题回答完，基本就能判断该不该上 Agent 了。我自己的经验是，大概只有百分之二十的需求真正需要 Agent，剩下百分之八十都可以用更简单、更可控的方案解决。

4.2 一个真实的决策案例：从 Agent 方案退回工作流方案

去年我接了一个需求，帮一个内部团队做会议纪要自动生成。需求方一开始说得很明确：要一个 Agent，能自动听会议录音、提取待办事项、分配给对应负责人、发通知。

我按照 Agent 思路设计了一版方案：模型先转写录音，然后自主决定哪些内容是待办、哪些是讨论、哪些是决策，再自主决定待办分配给谁，最后调用通知接口。Demo 跑起来效果不错，但一上真实数据就出问题。模型有时候把讨论内容当成待办，有时候把待办分配给错误的人，有时候漏掉一些待办。

后来我退了一步，把流程拆成固定的几步：第一步，转写录音；第二步，用模型提取所有可能包含待办事项的段落；第三步，用规则匹配负责人（基于人名和部门映射表）；第四步，人工确认后再发通知。整个流程里模型只做第二步的提取，不做分配决策。

这个方案上线后，待办提取的召回率大概百分之八十五，准确率大概百分之九十，剩下的由人工修正。需求方很满意，因为人工修正的成本远低于他们预期的“全自动”方案。而且因为流程固定，他们可以清楚地知道每一步在做什么，出了问题也知道去哪里改。

4.3 混合方案：在关键节点保留人的判断

完全自主的 Agent 和完全固定的工作流之间，还有一个很实用的中间态：在关键节点保留人的判断。

比如一个内容审核场景，你可以让模型先做初步判断，把内容分成“明显合规”“明显违规”“不确定”三类。明显合规的直接放行，明显违规的直接拦截，不确定的转人工审核。这样既利用了模型的效率，又在关键节点保留了人的判断。

这种混合方案的好处是风险可控、体验可调。你可以根据业务需求调整人工介入的比例，比如初期人工介入多一些，随着模型效果提升逐步减少。而且因为人工审核的数据可以回流训练模型，模型效果会越来越好。

我在多个项目里用了这个思路，效果都很稳定。关键是要设计好“不确定”的判定标准，让模型知道什么时候该说“我不确定”。这个标准可以通过 prompt 来定义，也可以通过微调来训练。

5. 常见问题与排查技巧实录

5.1 Agent 项目最常见的五个坑

第一个坑是工具描述写得太模糊。模型调用工具的效果很大程度上取决于工具描述的质量。如果描述里只写“查询数据”，模型不知道查什么数据、怎么查、返回什么格式。我后来养成了一个习惯，每个工具的描述都包含三部分：这个工具做什么、什么时候用、输入输出格式是什么。

第二个坑是没有设置最大步数。Agent 有时候会陷入循环，反复调用同一个工具。一定要设置最大步数限制，超过就强制终止并返回当前结果。我一般设置五到八步，具体取决于任务复杂度。

第三个坑是没有记录中间状态。Agent 的每一步决策都应该被记录下来，包括调用了什么工具、传了什么参数、返回了什么结果。这样出问题的时候才能定位。我后来在项目里加了一个日志层，把每一步的输入输出都存下来，排查问题的效率提升了很多。

第四个坑是过度依赖模型的判断。有些判断其实可以用规则做，比如“如果金额大于一万就转人工”，这种确定性规则不要交给模型。模型只用来处理规则覆盖不到的情况。

第五个坑是没有降级方案。Agent 调用失败的时候，应该有降级方案。比如工具调用超时，可以返回一个默认结果或者转人工处理，而不是直接报错。

5.2 排查技巧速查表

5.3 我踩过的一个典型坑：工具返回值格式不一致

有一次我做一个数据查询 Agent，挂了三个工具：查用户信息、查订单信息、查物流信息。三个工具是不同团队提供的，返回格式各不相同。查用户返回的是 JSON，查订单返回的是 XML，查物流返回的是纯文本。

结果模型在处理这些返回值的时候经常出错，因为它需要理解三种不同的格式。后来我加了一个适配层，把所有工具的返回值统一转成 JSON 格式再给模型。问题就解决了。

这个坑让我意识到，Agent 的稳定性不仅取决于模型本身，还取决于你给它的输入是否规范。工具返回值格式统一、字段命名一致、错误码规范，这些看似琐碎的细节，对 Agent 的稳定性影响很大。

6. 我对 AI 应用开发的一点个人体会

做了两年多 AI 应用，我最大的体会是：不要被范式绑架。Agent 是一个有用的范式，但它不是唯一的选择，也不是最好的选择。很多时候，一个简单的工作流、一个固定的模板、一条明确的规则，比一个自主决策的 Agent 更有效。

我现在做新项目的时候，会先问自己：这个需求里，哪些部分是确定的，哪些部分是不确定的？确定的部分用代码写死，不确定的部分才交给模型。模型也不是只能用一种方式调用，有的地方用生成，有的地方用分类，有的地方用提取，根据任务特点选择最合适的方式。

还有一个体会是：AI 应用的核心竞争力不在模型，而在工程。模型能力大家都差不多，你能调用的 API 别人也能调用。真正拉开差距的是你怎么设计流程、怎么组织数据、怎么处理异常、怎么优化成本。这些工程层面的东西，才是 AI 应用开发真正需要积累的能力。

最后分享一个小技巧。如果你正在纠结要不要上 Agent，可以先做一个最小可行版本，用最简单的方式实现核心功能，然后观察哪些地方模型做得不好，再针对性地引入更复杂的方案。不要一上来就设计一个全自主的 Agent，那样你很可能花了很多时间，最后发现大部分复杂度都是不必要的。