生产级开发中，不要无脑追求做Agent

上一篇文章《研究了一圈，我终于搞清楚“Agent框架”这些概念》我们聊了工作流、Agent产品、Agent框架这几个概念的区别，核心结论是"大部分企业场景本质上是工作流"。那篇更多是概念辨析，把东西分清楚。

这篇我想往下推一步，聊一个更实际的问题：在生产环境中，AI到底应该放在什么位置？

这个问题听起来简单，但我发现很多团队（包括我自己之前）的思考方向从一开始就是反的。

先说一个思考模型：AI的价值是"补断点"

在AI出现之前，企业的自动化已经做了很多年了。ERP、审批流、数据pipeline、定时任务，这些东西能自动的早就自动了。

那自动化卡在哪里？

卡在"需要人判断"的节点上。

流程跑到某个点，系统没法自己往下走了，因为接下来该怎么做取决于一个需要"理解""分析""判断"的决策。于是流程停下来，等人来看一眼、拍个板，然后再继续往下跑。

这些节点就是自动化链条上的"断点"。

举个例子。一个采购审批流程：提交申请、预算校验、领导审批、下单、入库。其中"预算校验"是机械的，系统自己能做。但"领导审批"这个环节，很多时候不是简单的看金额过不过阈值，而是要判断"这笔采购合不合理""这个供应商靠不靠谱""当前预算紧不紧张"。这种判断以前只能靠人，流程到这里就断了，等人来接。

这些判断，人一直知道该怎么做，只是没法把自己的判断逻辑写成机械的代码。你让一个采购经理判断"这笔采购合不合理"，他能判断，但你让他写成if-else，他写不出来。没法穷举，没法用规则描述。

大模型的突破就在这里：它让这些以前写不成代码的判断逻辑，可以通过自然语言描述和执行了。 你用prompt告诉它判断标准，它就能做出和人类专家相似的判断。

所以AI在生产系统中的价值，本质上是补断点，让自动化链条更完整。

注意，是"补断点"，不是"换架构"。工作流还是那个工作流，软件还是那个软件，只不过原来有几个环节要等人，现在AI可以顶上去了。

这个思考模型很重要，因为它决定了你的工程思路：你不是在"造一个Agent系统"，你是在原有系统的基础上，找到那些断点，评估哪些可以用AI补上，然后把AI嵌进去。

但很多人的思路是反的

我观察到一个很普遍的现象：很多团队在引入AI的时候，思考的起点不是"我的业务流程哪里有断点需要补"，而是"我要做一个Agent"。

先选了Agent这个形态，然后再去找业务场景往里套。

这个思路看似没什么大问题，但其实从根上就偏了。

更要命的是，很多人还有一个隐含的判断：觉得做Agent是"高级"的，做工作流、做传统软件是"低级"的。好像用了大模型做决策就先进，老老实实写if-else、画流程图就是落后。

这个判断是错的。

我仔细想过，"能在点上做判断"和"应该在面上做主"是两件完全不同的事。

打个比方。一个有经验的质检员能判断产品合不合格，这是一种点状的能力。但你不会因此就让质检员来指挥整条生产线的排产调度。排产靠的是确定性的规则、严格的流程和可预测的产出，不是靠某个人的判断力。

AI也是一样。大模型确实能做一些以前只有人才能做的判断，但这不意味着你应该让它来主导整个业务流程。

一个系统里可能有100个环节，其中90个是确定性的机械操作，用普通代码和工作流就能搞定，而且搞得非常稳定。剩下10个以前需要人来判断，现在AI可以接手其中七八个。

正确的做法是什么？只在这七八个点上嵌入AI，其他地方原封不动。

而不是因为AI在这七八个点上表现不错，就推导出"让AI来管全部100个环节"。后者不是升级，是退步。你把90个本来确定性很高的环节也交给了一个概率模型，凭空引入了不确定性。

所以我的观点是：从业务流程出发，在需要的地方加入一点智能，这才是正路。先决定"我要做一个Agent"，然后围着它去找场景，这是追概念。

软件工程的确定性不是"low"，在生产环境中，确定性是最值钱的东西。

那什么场景确实需要Agent？

说到这里，可能有人会问：你是不是在说Agent完全没用？

不是。Agent确实有它的刚需场景。我经过仔细思考，觉得至少有这几类场景是工作流搞不定、必须用Agent的。

第一类：状态空间大到你根本画不完流程图的场景。

最典型的例子是自动驾驶。路上会遇到什么情况是没法穷举的：一个球滚到马路上、前车突然开门、逆光加暴雨同时出现。你没办法提前把所有情况都写成if-else分支，因为组合是无限的。这种场景天然需要一个能实时感知、自主决策的系统。

类似的还有复杂环境中的仓储机器人路径规划、开放世界中的探索性任务。

第二类：对手在持续变化的对抗性环境。

网络安全就是一个好例子。攻击者不会按你的剧本来，他们在不断发明新的攻击手段。如果你的防御策略是固定的工作流，本质上就是在用昨天的规则打今天的仗。类似的还有欺诈检测，骗术在不断进化，固定规则永远滞后。

第三类：规则本身在高频变化、工作流的维护成本反超Agent的场景。

比如大型平台的内容审核。违规内容的形态每天都在变，梗、隐语、新的擦边方式层出不穷。如果用工作流来做，就得不停加规则、加分支。到最后规则库膨胀到没人能维护，它的可靠性反而下降了。这时候一个能理解语义的AI反而比穷举规则更靠谱。

但这里有一个很重要的限定：以上这些场景，绝大部分是大公司或者特定行业才会面对的。

大多数中小公司的业务场景，规则是有限的、变化是缓慢的、操作规范是可以穷举的。对这些场景来说，老老实实做工作流、做确定性的软件，就是最优解。不存在"太low"的问题，只有适不适合的问题。

所以结论是：Agent有它的战场，但那个战场比很多人以为的要小得多。 在评估要不要用Agent之前，先诚实地问自己一个问题：我的场景，真的画不出流程图吗？

如果要嵌入AI，怎么嵌才靠谱？

假设你确实识别出了某些节点需要AI来做判断，那接下来的问题是：怎么把AI嵌进工作流才不会翻车？

这里我有一个框架，我把它叫做"领域决策层"。核心思想就一句话：即使你用了Agent的能力，也要把它关在笼子里。

具体怎么关？我拆成五个部分。

输入约束。 不要把所有信息都丢给AI让它自由发挥。只给它当前这个决策节点需要的信息，提前帮它筛好。比如在贷款审批的风控环节，只给它征信摘要、近期借贷记录、行业风险评级这几样东西，别把整个客户档案都塞进去。信息越聚焦，判断越稳定。

输出规范。 AI的输出不能是一段自由文本，必须是结构化的结果。比如必须返回：风险等级（高/中/低）、关键风险因子（具体列出来）、建议动作（通过/拒绝/转人工）、置信度（0到1的数值）。这个结构是你提前定义好的，AI必须按格式返回，否则不予采纳。

决策边界。 明确告诉AI"你只能在什么范围内做决定"。比如贷款金额超过50万的，不管AI怎么判断，一律转人工。置信度低于0.7的，也一律转人工。AI的决策权被严格限定在一个安全区域内，超出边界的，工作流直接接管走兜底路径。

知识注入。 不要让AI用它的通用知识来猜你们行业的规则。把你们的风控标准、监管要求、历史案例明确地喂给它。可以写在system prompt里，也可以通过RAG动态检索相关文档。让它带着你的行业知识做判断，而不是凭感觉。

校验和兜底。 AI返回结果之后，工作流不能直接用，要先过一道校验。比如检查输出格式对不对、风险等级和风险因子之间是否逻辑自洽（说"低风险"但列了三个高危因子，这明显有问题）、有没有触发任何硬性规则。校验不通过的，要么让AI重新生成，要么直接走兜底路径。

把这五层加上去之后，AI在你的系统里就不是一个"自由行动的Agent"，而是一个被严格管理的组件。它只在你划定的范围内发挥，超出范围就有人（或者规则）兜底。

这跟"做一个Agent让它自己跑"是完全不同的工程思路。

写在最后

从业务出发加入一点智能，而不是从智能出发去找业务。

这是我最近在做Agent还是做工作流这件事上最大的体会。

我建了一个AI学习研究群，目前几十来人，都是在真正动手搞AI的人。如果你也在自己跑模型、写代码、做项目，欢迎点赞关注转发一键三连，然后加我微信，备注写清"你在做的AI方向"，聊得来的话我拉你进群。纯围观的和小白就不加了，有一定门槛。