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. 实操怎么判断一个需求该不该上 Agent4.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 排查技巧速查表问题现象可能原因排查方法解决方案模型不调用工具工具描述不清晰或 prompt 没引导检查工具描述和 prompt补充工具使用场景说明模型反复调用同一工具没有步数限制或工具返回结果不明确查看调用日志设置最大步数优化返回格式输出格式不稳定prompt 约束不够或模型能力不足对比多次输出加模板约束或换更强模型响应时间过长工具调用链太长或模型推理慢记录每步耗时减少工具数量或换轻量模型成本超预期模型调用次数过多或用了大模型统计 token 消耗用规则前置过滤或换小模型5.3 我踩过的一个典型坑工具返回值格式不一致有一次我做一个数据查询 Agent挂了三个工具查用户信息、查订单信息、查物流信息。三个工具是不同团队提供的返回格式各不相同。查用户返回的是 JSON查订单返回的是 XML查物流返回的是纯文本。结果模型在处理这些返回值的时候经常出错因为它需要理解三种不同的格式。后来我加了一个适配层把所有工具的返回值统一转成 JSON 格式再给模型。问题就解决了。这个坑让我意识到Agent 的稳定性不仅取决于模型本身还取决于你给它的输入是否规范。工具返回值格式统一、字段命名一致、错误码规范这些看似琐碎的细节对 Agent 的稳定性影响很大。6. 我对 AI 应用开发的一点个人体会做了两年多 AI 应用我最大的体会是不要被范式绑架。Agent 是一个有用的范式但它不是唯一的选择也不是最好的选择。很多时候一个简单的工作流、一个固定的模板、一条明确的规则比一个自主决策的 Agent 更有效。我现在做新项目的时候会先问自己这个需求里哪些部分是确定的哪些部分是不确定的确定的部分用代码写死不确定的部分才交给模型。模型也不是只能用一种方式调用有的地方用生成有的地方用分类有的地方用提取根据任务特点选择最合适的方式。还有一个体会是AI 应用的核心竞争力不在模型而在工程。模型能力大家都差不多你能调用的 API 别人也能调用。真正拉开差距的是你怎么设计流程、怎么组织数据、怎么处理异常、怎么优化成本。这些工程层面的东西才是 AI 应用开发真正需要积累的能力。最后分享一个小技巧。如果你正在纠结要不要上 Agent可以先做一个最小可行版本用最简单的方式实现核心功能然后观察哪些地方模型做得不好再针对性地引入更复杂的方案。不要一上来就设计一个全自主的 Agent那样你很可能花了很多时间最后发现大部分复杂度都是不必要的。
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. 实操怎么判断一个需求该不该上 Agent4.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 排查技巧速查表问题现象可能原因排查方法解决方案模型不调用工具工具描述不清晰或 prompt 没引导检查工具描述和 prompt补充工具使用场景说明模型反复调用同一工具没有步数限制或工具返回结果不明确查看调用日志设置最大步数优化返回格式输出格式不稳定prompt 约束不够或模型能力不足对比多次输出加模板约束或换更强模型响应时间过长工具调用链太长或模型推理慢记录每步耗时减少工具数量或换轻量模型成本超预期模型调用次数过多或用了大模型统计 token 消耗用规则前置过滤或换小模型5.3 我踩过的一个典型坑工具返回值格式不一致有一次我做一个数据查询 Agent挂了三个工具查用户信息、查订单信息、查物流信息。三个工具是不同团队提供的返回格式各不相同。查用户返回的是 JSON查订单返回的是 XML查物流返回的是纯文本。结果模型在处理这些返回值的时候经常出错因为它需要理解三种不同的格式。后来我加了一个适配层把所有工具的返回值统一转成 JSON 格式再给模型。问题就解决了。这个坑让我意识到Agent 的稳定性不仅取决于模型本身还取决于你给它的输入是否规范。工具返回值格式统一、字段命名一致、错误码规范这些看似琐碎的细节对 Agent 的稳定性影响很大。6. 我对 AI 应用开发的一点个人体会做了两年多 AI 应用我最大的体会是不要被范式绑架。Agent 是一个有用的范式但它不是唯一的选择也不是最好的选择。很多时候一个简单的工作流、一个固定的模板、一条明确的规则比一个自主决策的 Agent 更有效。我现在做新项目的时候会先问自己这个需求里哪些部分是确定的哪些部分是不确定的确定的部分用代码写死不确定的部分才交给模型。模型也不是只能用一种方式调用有的地方用生成有的地方用分类有的地方用提取根据任务特点选择最合适的方式。还有一个体会是AI 应用的核心竞争力不在模型而在工程。模型能力大家都差不多你能调用的 API 别人也能调用。真正拉开差距的是你怎么设计流程、怎么组织数据、怎么处理异常、怎么优化成本。这些工程层面的东西才是 AI 应用开发真正需要积累的能力。最后分享一个小技巧。如果你正在纠结要不要上 Agent可以先做一个最小可行版本用最简单的方式实现核心功能然后观察哪些地方模型做得不好再针对性地引入更复杂的方案。不要一上来就设计一个全自主的 Agent那样你很可能花了很多时间最后发现大部分复杂度都是不必要的。
