“龙虾”这个比喻是我在一个技术群里看到的。当时有人吐槽自家公司的大模型Agent项目：GPU买了、算法团队扩了、Prompt调了一版又一版，结果线上效果越来越差，账单却越来越厚。评论区一句话总结——“像养龙虾，越养越贵，越用越蠢”。话糙理不糙，这几乎概括了过去两年我在多家企业里观察到的AI Agent落地困境。这篇文章我不聊算法细节，也不抄论文，纯粹站在企业架构师的角度，聊一聊为什么这么多公司的Agent项目会走上“越养越贵、越用越蠢”的路，以及我们踩过坑之后总结出来的避坑方法。如果你是技术负责人、架构师，或者正要立项做企业级AI Agent，这应该是一份能直接照着用的实战参考。1. 先别急着骂大模型：两笔糊涂账是怎么算出来的1.1 “越养越贵”的钱，到底烧在了哪儿很多团队一开始算账很简单：模型调用一次几毛钱，一个月几万块的Token费用，扛得住。但真正上线三个月后再看财务报表，你会发现钱的去向完全是另一回事。第一块是算力基建。为了跑私有化模型，采购GPU服务器、扩容存储、搭向量数据库集群，动辄几十万起步。第二块是人力，这不是一两个算法工程师的问题，而是“Prompt工程师+后端开发+运维+数据标注”一整条链路上的人都在为这个项目服务。第三块是迭代成本——每一轮模型优化、知识库更新、效果回归测试，背后消耗的人天和算力都被记进了项目的隐性成本。最容易被忽略的是第四块：集成成本。Agent要接入企业内部的ERP、CRM、工单系统，每个系统的接口对接、权限改造、数据清洗，都要钱要人。好多项目就是死在这一步——模型本身不贵，贵的是让模型“学会用你们公司的系统”。1.2 “越用越蠢”不是错觉，是系统性的能力衰减大模型不会真的“变笨”，但你的Agent会。原因很简单：Agent是一个软件系统，不是单个模型。系统里的任何一个环节退化，都会表现为“效果变差”。常见的情况是，Prompt越写越长，功能越叠越多，模型要在一个上下文窗口里同时处理十几个指令，结果每个都做得马马虎虎。再比如知识库不断往里面灌数据，新旧文档矛盾、内容过时，模型检索出来的东西本身就是错的。又比如Agent调用的工具越来越多，工具之间的状态没有管理好，经常出现“调了A工具忘了B工具的结果”这种低级失误。这些都是典型的架构问题，不是模型问题。但很多人第一反应是“换个更大的模型试试”，结果账单翻倍，效果纹丝不动，这就是“越养越贵、越用越蠢”的死循环。2. 架构师视角：Agent是一个需要治理的系统，不是写Prompt2.1 先分清你做的到底是Workflow还是Agent这是我在评审项目时问的第一句话。不说清这个，后面全是糊涂账。Workflow是固定的流程：用户输入，走完第1步、第2步、第3步，每一步做什么都提前定死。好比流水线，稳定、可控、成本可预测。Agent则是有自主决策能力的系统：它自己决定下一步调用哪个工具、需不需要追问用户、什么时候结束。灵活，但代价是行为不可穷举。很多业务场景根本不需要Agent。比如“根据订单号查物流状态”，固定流程就能解决，你非给它上Agent，模型就会“自由发挥”，可能多调两个没必要的接口，也可能在对话里自作主张地说一些业务上不允许的话。我的建议是：能用Workflow解决的，绝不上Agent。一个系统里80%的固定流程加20%的Agent决策，是性价比最高的组合。2.2 把Agent拆成可治理的分层架构企业级Agent和Demo最大的区别，就是能不能被治理。我习惯把Agent系统分成以下层面来设计：接入层：统一处理用户请求、身份认证、权限校验。编排层：负责理解意图、制定计划、调用工具，是Agent“大脑”所在。技能层：封装具体的工具和API，每个技能必须有明确的输入输出定义。知识层：管理RAG的知识库、向量索引、权限过滤。治理层：负责日志、审计、监控、评测、限流、熔断。这么拆的好处是，每一层的问题都可以单独排查和处理。线上效果差了，先看是哪一层出的问题——是知识库里多了脏数据，还是某个工具接口超时，而不是对着整个Agent系统干瞪眼。2.3 状态管理：让Agent“记住”什么，比让它“算对”什么更重要企业级Agent一个很容易翻车的点，是状态管理。模型本身是无状态的，它每次调用都是“失忆”的，靠上下文窗口里的内容来假装有记忆。可上下文窗口就这么大，塞进去的内容多了，效果必然下降。架构上一定要把状态显式地管理起来。业务状态放在数据库或缓存里，该持久化就持久化；对话状态只保留最近几轮；超过阈值的历史对话，抽成摘要后再放回上下文。我们内部的原则是：上下文窗口只放“当前任务必需的信息”，绝不当垃圾桶用。另外还要管理“工具状态”。Agent调用了一个查询接口拿到结果，这个结果放在哪，后续步骤怎么引用，都需要有明确的约定。否则模型很快会在多轮工具调用中迷失，出现“刚才查了A，现在却拿A的结果当B来用”的弱智错误。3. 成本失控的隐蔽漏洞：四个最容易烧钱的地方3.1 Token“漏损”：每个多余的步骤都在二次收费很多团队的Token账单爆炸，不是因为用户问得多，而是因为Agent内部调用得太频繁。每一次工具调用都要把历史信息重新发给模型一遍，成本就是“输入Token × 调用次数”。一个原本一次就能回答的问题，Agent可能为了确认一下又调了一次工具，成本直接翻倍。解决思路是给Agent加“成本感知”，在编排层做约束：能用已有信息回答的就不要再调用新工具；多个工具可以并行调用的就不要串行调用；越是简单的任务，越是走短链路。上线前一定要做一次“单次对话平均Token消耗”的基准测试，设定上限，超了就报警排查。3.2 基建重复建设：每个团队都在造半条“龙虾”大公司里最常见的浪费，是各个业务线各自为政，分别搭了向量数据库、模型网关和Prompt调试平台。A组花了三个月调出来的知识库优化方案，B组不知道，又从零开始踩一遍坑。架构上的解法就是“平台化”。模型接入、知识库、Agent编排引擎、评测系统，尽量收拢成企业内部的公共平台，业务团队在上面做配置而不是做开发。算过一笔账，平台化初期会慢一点，但长远看能省掉至少一半的重复成本。3.3 用人成本：算法团队用在了不该用的地方还有一个隐蔽成本，是“人才错配”。很多公司让资深算法工程师天天调Prompt，让开发工程师维护知识库文档，这是巨大的浪费。Prompt调优到了一定程度就是体力活，有标准化的调试流程之后，初级工程师甚至运营人员都能做。算法团队的精力应该花在评测体系、模型选型和效果优化上，而不是陷入“这里加一句提示词试试”的循环里。3.4 成本模型：要算单位业务成本，别只盯着GPU使用率我见过不少项目汇报PPT，写的是“GPU利用率85%”“模型调用成功率99%”，但问到“这个Agent帮公司处理一笔业务的实际成本是多少”，没有人答得上来。技术指标好看不等于业务划算。正确成本模型应该是：单次业务成本 = 总成本（算力+人力+基建摊销） ÷ 有效处理业务量。如果你的Agent处理一万次咨询需要三个运维天天维护，那单次成本可能比人工客服还贵。上线前把这个公式定下来，之后每个迭代都用它评估，比什么指标都实在。4. 效果衰减的三个典型路径：为什么会越用越蠢4.1 上下文污染：Prompt越改越长，效果越来越差项目上线后，业务方会不断提需求：加一个规则、加一个话术、加一个限制。每个需求最终都变成Prompt里加一段话。三个月后，Prompt可能膨胀到几千字，模型在这么多指令里迷失，原来能稳定执行的核心任务反而不稳了。解决方法是定期做Prompt“瘦身”。每个Agent维护一个“意图清单”，每加一条规则就问三个问题：这条规则服务哪个场景？如果用户问的问题和它无关，会不会造成干扰？能不能把它放到后处理逻辑里，而不是塞进Prompt？很多规则用代码做硬校验比让模型自己判断靠谱得多。4.2 知识库腐烂：旧数据比没有数据更危险RAG系统上线时效果惊艳，半年后效果下滑，大概率是知识库出了问题。文档更新不及时，新版流程已经上线，库里还是旧版描述；多个来源的文档互相矛盾，模型检索的时候随机抽一个，同一个问题今天答案和明天不一样。这需要给知识库建立生命周期管理。每篇文档必须有责任人、有效期限、版本号，到期的自动提醒复核。知识库里每类数据要配置“权威来源”，检索结果里优先展示权威来源的内容。宁缺毋滥，检索相关性低的数据宁可不入库。4.3 评测缺失：没有“及格线”的Agent必然退化很多团队改Agent纯靠“感觉”——业务方试了几个问题觉得不错，就上线了；下个版本改坏了也没人知道。因为没有自动化的回归评测，每次改动都在裸奔。要建一套和业务场景强绑定的评测集，至少几百条真实问题，覆盖高频场景、边界场景、危险场景。每次改Prompt、换模型、调参数，都拿这套评测集跑一遍，对比通过率。没有这套东西，所谓“优化”就只是碰运气。5. 落地避坑清单：从选型到上线的八个关键决策点5.1 决策一：这个场景真的需要大模型吗很多场景用规则引擎、关键词匹配、甚至一个SQL查询就能解决。大模型的优势是理解复杂语义和生成自然语言，如果场景里没有这两个需求，就别硬上。常用判断标准：输入是不是开放式的自然语言？输出是不是需要灵活生成？前者是必要条件，后者是充分条件。5.2 决策二：模型选型，不是越大越好企业级场景里，模型选型的优先级是：效果 > 成本 > 速度 > 参数规模。有些内部工具场景，一个轻量模型加一套好的规则，效果轻松打败超大模型。建议做一次系统的“模型筛选”：拿同样的评测集，跑市面上主流闭源和开源模型，按“效果达标+成本最低”选，而不是按“最强最贵”选。私有化部署不要盲目追随，只有当数据合规要求不允许出域，或者调用量大到API费用远超自建算力成本时，私有化才划算。很多公司买了几台GPU服务器养着，利用率不到两成，纯纯的“龙虾养殖户”。5.3 决策三：权限管控必须前置Agent会拿着企业的内部数据回答问题，权限设计必须从第一天就做好。核心原则是“数据最小可见”——Agent只能看到当前用户有权限访问的数据。否则就会出现普通员工问出高管薪酬的严重事故。这块我建议让安全团队提前介入，不要等上线前再补。5.4 决策四：可观测性体系不能省Agent的黑盒属性决定了排查问题的难度。日志至少要记录四类信息：用户输入和最终输出，这个必须有模型中间推理过程（至少记录关键的“思考”步骤摘要）每一次工具调用的参数、返回结果、耗时评测记录：命中/未命中、命中哪个场景、置信度有了这些日志，线上出了问题才能回溯。没有可观测性的Agent项目，等于开着一辆没有仪表盘的车，出了故障只能停车靠猜。5.5 决策五：人工兜底必须存在Agent不能“独自作战”。高风险操作（比如自动下单、自动退款、对外发布内容）必须设置人工审核节点。低置信度的回答，让Agent老实说“不确定”，不要让模型硬编。企业的容错率比互联网Demo低得多，一个幻觉回答可能就会引发投诉甚至法律纠纷。5.6 决策六：上线不等于结束，迭代节奏要定好产品上线只是开始，后续的Prompt优化、知识库更新、模型升级、评测回归，都需要有明确的责任人和流程。建议设置“双周迭代”节奏，每个双周做一次效果回顾，看评测集通过率、用户反馈、成本数据，再决定下个双周改什么。6. 一个虚构案例复盘：某零售企业AI助手如何从“好用”变成“龙虾”6.1 项目初期：一切都好得不像真的这是我在一次技术交流中听到的案例，细节做过脱敏处理。某零售企业上线了一个面向顾客的AI导购助手，最初只接了一个商品检索功能，回答库存、价格、促销活动这类问题。上线第一个月效果非常好，人工客服量下降了30%，管理层大喜。为什么好？因为范围足够小，知识库干净，模型调用链路短，上下文基本没有冗余信息。那时候的Agent，是标准的“小而美”。6.2 半年后：项目开始失控半年后，这个项目经历了三轮“大跃进”：先接入订单查询和售后流程，又接入了会员积分体系，还接了内部工单系统。Prompt从几十行膨胀到几百行，知识库里塞满了各个渠道复制过来的文档，有些已经过期了。用户开始投诉AI答非所问。客服系统里，Agent经常把“无货”的商品说成“有货”，把“已经退款”的订单说成“退款处理中”。更糟的是成本，由于链路变长了，单次对话平均Token消耗涨到了初期的五倍。项目陷入了一个尴尬境地——花的钱多了，口碑反而坏了。6.3 架构重构：我们最终做的三件事这个项目后来做了一次大规模重构，核心动作有三个。第一，把功能拆分。一个Agent变成三个：售前导购Agent、售后处理Agent、内部知识问答Agent。每个Agent只负责自己的领域，不允许跨域调用工具。想跨域？走显式转接，交给对应Agent处理。第二，给知识库做了“大扫除”。所有的过期文档拆分出来，冻结归档，不在RAG检索范围内；每篇生效文档标了有效期和负责人，到期预警。第三，恢复了成本管控和评测回归。单次对话Token上限设到一条硬红线，超过就熔断降级；跑通了一套自动评测流水线，每次发版之前自动跑评测。重构之后再观察了三个月，效果恢复到了初期的水准，成本降下来了四成。这个故事没什么神奇的操作，就是回到架构的基本常识。7. 常见问题速查表：企业Agent踩坑自查症状可能的根因排查方向对策回答越来越慢上下文膨胀、工具串行调用查单次对话Token量和调用链Prompt瘦身，并行化工具调用简单问题频繁犯错Prompt指令过多、上下文干扰跑评测集，看失败场景分布摘除非核心指令，规则后置同类问题答案不稳定知识库多个来源矛盾检索引擎里查召回文档配置权威来源，清理矛盾数据账单月度翻倍工具滥用、模型选型过重看Token消耗明细和调用次数加成本约束，降级小模型结果“一本正经胡说”缺少知识约束或权限过滤看反馈日志中幻觉类问题占比接业务数据校验，禁用模型自由发挥上线新版本后效果暴跌没有回归评测对比新旧版本评测集通过率建立自动化评测流水线8. 写在最后的一点个人体会做AI Agent这几年，我最深的体会是：这个领域的门槛不在“把模型跑起来”，而在“让系统长期稳定地跑下去”。很多人刚接触Agent的时候，会被它的“智能”迷住，觉得它能像人一样思考，解决一切问题。实际落地才发现，它更像一个能力不错但很容易走神的新员工——你需要给它明确的工作边界、清晰的流程标准、充分的日志留痕，还要定期考核它的工作质量。如果你没做这些，它的表现就会变成“越养越贵，越用越蠢”。从我接触过的项目来看，凡是成功的落地案例，都做对了同一件事：把Agent当作企业IT系统的一部分，而不是一个独立的“AI玩具”。用架构的思维去设计它、治理它、度量它，它才会真正变成一件好用的工具。最后再分享一个小技巧：在你自己的项目里，找一个最耗钱但最简单的功能，把它从Agent手势改成固定脚本。你会发现成本掉下来一大截，稳定性还上去了。这种“给Agent减负”的思路，往往比调一个更强模型划算得多。
“龙虾”这个比喻是我在一个技术群里看到的。当时有人吐槽自家公司的大模型Agent项目：GPU买了、算法团队扩了、Prompt调了一版又一版，结果线上效果越来越差，账单却越来越厚。评论区一句话总结——“像养龙虾，越养越贵，越用越蠢”。话糙理不糙，这几乎概括了过去两年我在多家企业里观察到的AI Agent落地困境。这篇文章我不聊算法细节，也不抄论文，纯粹站在企业架构师的角度，聊一聊为什么这么多公司的Agent项目会走上“越养越贵、越用越蠢”的路，以及我们踩过坑之后总结出来的避坑方法。如果你是技术负责人、架构师，或者正要立项做企业级AI Agent，这应该是一份能直接照着用的实战参考。1. 先别急着骂大模型：两笔糊涂账是怎么算出来的1.1 “越养越贵”的钱，到底烧在了哪儿很多团队一开始算账很简单：模型调用一次几毛钱，一个月几万块的Token费用，扛得住。但真正上线三个月后再看财务报表，你会发现钱的去向完全是另一回事。第一块是算力基建。为了跑私有化模型，采购GPU服务器、扩容存储、搭向量数据库集群，动辄几十万起步。第二块是人力，这不是一两个算法工程师的问题，而是“Prompt工程师+后端开发+运维+数据标注”一整条链路上的人都在为这个项目服务。第三块是迭代成本——每一轮模型优化、知识库更新、效果回归测试，背后消耗的人天和算力都被记进了项目的隐性成本。最容易被忽略的是第四块：集成成本。Agent要接入企业内部的ERP、CRM、工单系统，每个系统的接口对接、权限改造、数据清洗，都要钱要人。好多项目就是死在这一步——模型本身不贵，贵的是让模型“学会用你们公司的系统”。1.2 “越用越蠢”不是错觉，是系统性的能力衰减大模型不会真的“变笨”，但你的Agent会。原因很简单：Agent是一个软件系统，不是单个模型。系统里的任何一个环节退化，都会表现为“效果变差”。常见的情况是，Prompt越写越长，功能越叠越多，模型要在一个上下文窗口里同时处理十几个指令，结果每个都做得马马虎虎。再比如知识库不断往里面灌数据，新旧文档矛盾、内容过时，模型检索出来的东西本身就是错的。又比如Agent调用的工具越来越多，工具之间的状态没有管理好，经常出现“调了A工具忘了B工具的结果”这种低级失误。这些都是典型的架构问题，不是模型问题。但很多人第一反应是“换个更大的模型试试”，结果账单翻倍，效果纹丝不动，这就是“越养越贵、越用越蠢”的死循环。2. 架构师视角：Agent是一个需要治理的系统，不是写Prompt2.1 先分清你做的到底是Workflow还是Agent这是我在评审项目时问的第一句话。不说清这个，后面全是糊涂账。Workflow是固定的流程：用户输入，走完第1步、第2步、第3步，每一步做什么都提前定死。好比流水线，稳定、可控、成本可预测。Agent则是有自主决策能力的系统：它自己决定下一步调用哪个工具、需不需要追问用户、什么时候结束。灵活，但代价是行为不可穷举。很多业务场景根本不需要Agent。比如“根据订单号查物流状态”，固定流程就能解决，你非给它上Agent，模型就会“自由发挥”，可能多调两个没必要的接口，也可能在对话里自作主张地说一些业务上不允许的话。我的建议是：能用Workflow解决的，绝不上Agent。一个系统里80%的固定流程加20%的Agent决策，是性价比最高的组合。2.2 把Agent拆成可治理的分层架构企业级Agent和Demo最大的区别，就是能不能被治理。我习惯把Agent系统分成以下层面来设计：接入层：统一处理用户请求、身份认证、权限校验。编排层：负责理解意图、制定计划、调用工具，是Agent“大脑”所在。技能层：封装具体的工具和API，每个技能必须有明确的输入输出定义。知识层：管理RAG的知识库、向量索引、权限过滤。治理层：负责日志、审计、监控、评测、限流、熔断。这么拆的好处是，每一层的问题都可以单独排查和处理。线上效果差了，先看是哪一层出的问题——是知识库里多了脏数据，还是某个工具接口超时，而不是对着整个Agent系统干瞪眼。2.3 状态管理：让Agent“记住”什么，比让它“算对”什么更重要企业级Agent一个很容易翻车的点，是状态管理。模型本身是无状态的，它每次调用都是“失忆”的，靠上下文窗口里的内容来假装有记忆。可上下文窗口就这么大，塞进去的内容多了，效果必然下降。架构上一定要把状态显式地管理起来。业务状态放在数据库或缓存里，该持久化就持久化；对话状态只保留最近几轮；超过阈值的历史对话，抽成摘要后再放回上下文。我们内部的原则是：上下文窗口只放“当前任务必需的信息”，绝不当垃圾桶用。另外还要管理“工具状态”。Agent调用了一个查询接口拿到结果，这个结果放在哪，后续步骤怎么引用，都需要有明确的约定。否则模型很快会在多轮工具调用中迷失，出现“刚才查了A，现在却拿A的结果当B来用”的弱智错误。3. 成本失控的隐蔽漏洞：四个最容易烧钱的地方3.1 Token“漏损”：每个多余的步骤都在二次收费很多团队的Token账单爆炸，不是因为用户问得多，而是因为Agent内部调用得太频繁。每一次工具调用都要把历史信息重新发给模型一遍，成本就是“输入Token × 调用次数”。一个原本一次就能回答的问题，Agent可能为了确认一下又调了一次工具，成本直接翻倍。解决思路是给Agent加“成本感知”，在编排层做约束：能用已有信息回答的就不要再调用新工具；多个工具可以并行调用的就不要串行调用；越是简单的任务，越是走短链路。上线前一定要做一次“单次对话平均Token消耗”的基准测试，设定上限，超了就报警排查。3.2 基建重复建设：每个团队都在造半条“龙虾”大公司里最常见的浪费，是各个业务线各自为政，分别搭了向量数据库、模型网关和Prompt调试平台。A组花了三个月调出来的知识库优化方案，B组不知道，又从零开始踩一遍坑。架构上的解法就是“平台化”。模型接入、知识库、Agent编排引擎、评测系统，尽量收拢成企业内部的公共平台，业务团队在上面做配置而不是做开发。算过一笔账，平台化初期会慢一点，但长远看能省掉至少一半的重复成本。3.3 用人成本：算法团队用在了不该用的地方还有一个隐蔽成本，是“人才错配”。很多公司让资深算法工程师天天调Prompt，让开发工程师维护知识库文档，这是巨大的浪费。Prompt调优到了一定程度就是体力活，有标准化的调试流程之后，初级工程师甚至运营人员都能做。算法团队的精力应该花在评测体系、模型选型和效果优化上，而不是陷入“这里加一句提示词试试”的循环里。3.4 成本模型：要算单位业务成本，别只盯着GPU使用率我见过不少项目汇报PPT，写的是“GPU利用率85%”“模型调用成功率99%”，但问到“这个Agent帮公司处理一笔业务的实际成本是多少”，没有人答得上来。技术指标好看不等于业务划算。正确成本模型应该是：单次业务成本 = 总成本（算力+人力+基建摊销） ÷ 有效处理业务量。如果你的Agent处理一万次咨询需要三个运维天天维护，那单次成本可能比人工客服还贵。上线前把这个公式定下来，之后每个迭代都用它评估，比什么指标都实在。4. 效果衰减的三个典型路径：为什么会越用越蠢4.1 上下文污染：Prompt越改越长，效果越来越差项目上线后，业务方会不断提需求：加一个规则、加一个话术、加一个限制。每个需求最终都变成Prompt里加一段话。三个月后，Prompt可能膨胀到几千字，模型在这么多指令里迷失，原来能稳定执行的核心任务反而不稳了。解决方法是定期做Prompt“瘦身”。每个Agent维护一个“意图清单”，每加一条规则就问三个问题：这条规则服务哪个场景？如果用户问的问题和它无关，会不会造成干扰？能不能把它放到后处理逻辑里，而不是塞进Prompt？很多规则用代码做硬校验比让模型自己判断靠谱得多。4.2 知识库腐烂：旧数据比没有数据更危险RAG系统上线时效果惊艳，半年后效果下滑，大概率是知识库出了问题。文档更新不及时，新版流程已经上线，库里还是旧版描述；多个来源的文档互相矛盾，模型检索的时候随机抽一个，同一个问题今天答案和明天不一样。这需要给知识库建立生命周期管理。每篇文档必须有责任人、有效期限、版本号，到期的自动提醒复核。知识库里每类数据要配置“权威来源”，检索结果里优先展示权威来源的内容。宁缺毋滥，检索相关性低的数据宁可不入库。4.3 评测缺失：没有“及格线”的Agent必然退化很多团队改Agent纯靠“感觉”——业务方试了几个问题觉得不错，就上线了；下个版本改坏了也没人知道。因为没有自动化的回归评测，每次改动都在裸奔。要建一套和业务场景强绑定的评测集，至少几百条真实问题，覆盖高频场景、边界场景、危险场景。每次改Prompt、换模型、调参数，都拿这套评测集跑一遍，对比通过率。没有这套东西，所谓“优化”就只是碰运气。5. 落地避坑清单：从选型到上线的八个关键决策点5.1 决策一：这个场景真的需要大模型吗很多场景用规则引擎、关键词匹配、甚至一个SQL查询就能解决。大模型的优势是理解复杂语义和生成自然语言，如果场景里没有这两个需求，就别硬上。常用判断标准：输入是不是开放式的自然语言？输出是不是需要灵活生成？前者是必要条件，后者是充分条件。5.2 决策二：模型选型，不是越大越好企业级场景里，模型选型的优先级是：效果 > 成本 > 速度 > 参数规模。有些内部工具场景，一个轻量模型加一套好的规则，效果轻松打败超大模型。建议做一次系统的“模型筛选”：拿同样的评测集，跑市面上主流闭源和开源模型，按“效果达标+成本最低”选，而不是按“最强最贵”选。私有化部署不要盲目追随，只有当数据合规要求不允许出域，或者调用量大到API费用远超自建算力成本时，私有化才划算。很多公司买了几台GPU服务器养着，利用率不到两成，纯纯的“龙虾养殖户”。5.3 决策三：权限管控必须前置Agent会拿着企业的内部数据回答问题，权限设计必须从第一天就做好。核心原则是“数据最小可见”——Agent只能看到当前用户有权限访问的数据。否则就会出现普通员工问出高管薪酬的严重事故。这块我建议让安全团队提前介入，不要等上线前再补。5.4 决策四：可观测性体系不能省Agent的黑盒属性决定了排查问题的难度。日志至少要记录四类信息：用户输入和最终输出，这个必须有模型中间推理过程（至少记录关键的“思考”步骤摘要）每一次工具调用的参数、返回结果、耗时评测记录：命中/未命中、命中哪个场景、置信度有了这些日志，线上出了问题才能回溯。没有可观测性的Agent项目，等于开着一辆没有仪表盘的车，出了故障只能停车靠猜。5.5 决策五：人工兜底必须存在Agent不能“独自作战”。高风险操作（比如自动下单、自动退款、对外发布内容）必须设置人工审核节点。低置信度的回答，让Agent老实说“不确定”，不要让模型硬编。企业的容错率比互联网Demo低得多，一个幻觉回答可能就会引发投诉甚至法律纠纷。5.6 决策六：上线不等于结束，迭代节奏要定好产品上线只是开始，后续的Prompt优化、知识库更新、模型升级、评测回归，都需要有明确的责任人和流程。建议设置“双周迭代”节奏，每个双周做一次效果回顾，看评测集通过率、用户反馈、成本数据，再决定下个双周改什么。6. 一个虚构案例复盘：某零售企业AI助手如何从“好用”变成“龙虾”6.1 项目初期：一切都好得不像真的这是我在一次技术交流中听到的案例，细节做过脱敏处理。某零售企业上线了一个面向顾客的AI导购助手，最初只接了一个商品检索功能，回答库存、价格、促销活动这类问题。上线第一个月效果非常好，人工客服量下降了30%，管理层大喜。为什么好？因为范围足够小，知识库干净，模型调用链路短，上下文基本没有冗余信息。那时候的Agent，是标准的“小而美”。6.2 半年后：项目开始失控半年后，这个项目经历了三轮“大跃进”：先接入订单查询和售后流程，又接入了会员积分体系，还接了内部工单系统。Prompt从几十行膨胀到几百行，知识库里塞满了各个渠道复制过来的文档，有些已经过期了。用户开始投诉AI答非所问。客服系统里，Agent经常把“无货”的商品说成“有货”，把“已经退款”的订单说成“退款处理中”。更糟的是成本，由于链路变长了，单次对话平均Token消耗涨到了初期的五倍。项目陷入了一个尴尬境地——花的钱多了，口碑反而坏了。6.3 架构重构：我们最终做的三件事这个项目后来做了一次大规模重构，核心动作有三个。第一，把功能拆分。一个Agent变成三个：售前导购Agent、售后处理Agent、内部知识问答Agent。每个Agent只负责自己的领域，不允许跨域调用工具。想跨域？走显式转接，交给对应Agent处理。第二，给知识库做了“大扫除”。所有的过期文档拆分出来，冻结归档，不在RAG检索范围内；每篇生效文档标了有效期和负责人，到期预警。第三，恢复了成本管控和评测回归。单次对话Token上限设到一条硬红线，超过就熔断降级；跑通了一套自动评测流水线，每次发版之前自动跑评测。重构之后再观察了三个月，效果恢复到了初期的水准，成本降下来了四成。这个故事没什么神奇的操作，就是回到架构的基本常识。7. 常见问题速查表：企业Agent踩坑自查症状可能的根因排查方向对策回答越来越慢上下文膨胀、工具串行调用查单次对话Token量和调用链Prompt瘦身，并行化工具调用简单问题频繁犯错Prompt指令过多、上下文干扰跑评测集，看失败场景分布摘除非核心指令，规则后置同类问题答案不稳定知识库多个来源矛盾检索引擎里查召回文档配置权威来源，清理矛盾数据账单月度翻倍工具滥用、模型选型过重看Token消耗明细和调用次数加成本约束，降级小模型结果“一本正经胡说”缺少知识约束或权限过滤看反馈日志中幻觉类问题占比接业务数据校验，禁用模型自由发挥上线新版本后效果暴跌没有回归评测对比新旧版本评测集通过率建立自动化评测流水线8. 写在最后的一点个人体会做AI Agent这几年，我最深的体会是：这个领域的门槛不在“把模型跑起来”，而在“让系统长期稳定地跑下去”。很多人刚接触Agent的时候，会被它的“智能”迷住，觉得它能像人一样思考，解决一切问题。实际落地才发现，它更像一个能力不错但很容易走神的新员工——你需要给它明确的工作边界、清晰的流程标准、充分的日志留痕，还要定期考核它的工作质量。如果你没做这些，它的表现就会变成“越养越贵，越用越蠢”。从我接触过的项目来看，凡是成功的落地案例，都做对了同一件事：把Agent当作企业IT系统的一部分，而不是一个独立的“AI玩具”。用架构的思维去设计它、治理它、度量它，它才会真正变成一件好用的工具。最后再分享一个小技巧：在你自己的项目里，找一个最耗钱但最简单的功能，把它从Agent手势改成固定脚本。你会发现成本掉下来一大截，稳定性还上去了。这种“给Agent减负”的思路，往往比调一个更强模型划算得多。