只要做过企业 Agent 落地就一定逃不开两场战争内部经营闭环和 ToB 外部规模赋能。这不是指两套技术而是两条完全不同的战场。内部经营闭环是把 Agent 嵌进公司自己的业务流程里让数据、审批、执行、优化形成完整回路ToB 外部规模赋能则要把自己验证过的能力产品化交付给一个个外部客户还要能复制、能规模化。两仗都打过的人会知道这中间隔着一条从“工具好用”到“生意可做”的鸿沟。这篇内容我就按实际踩过的坑把两场战争的全局判断、场景选择、实操路线和常见问题都摊开来讲。1. 先看清全局两场战争两种打法1.1 什么是内部经营闭环内部经营闭环指的是 Agent 在企业的真实业务流程里产生动作并形成结果而不是只输出一段建议。比如财务报销、合同初审、客服工单、经营分析都算。关键点在于“闭环”两个字输入、处理、调用系统、生成结果、人工审批、归档、运营指标回流一步都不能少。Agent 必须“办事”不是“说话”。难点通常不在模型能力而在流程打通、数据权限、责任边界。很多团队内部 Agent 做了半年Demo 很漂亮但业务部门就是不用原因往往是没有形成闭环也没有人真正对结果负责。内部闭环要的是把某一条业务线的效率数字真正改掉比如单笔报销处理时间从 6 分钟降到 2 分钟而不只是“能回答报销政策”。闭环的四个要素我总结为触发要真实、工具要能落库、审核要有人、数据要回流。缺少任何一个Agent 就会退化成聊天机器人。1.2 什么是 ToB 外部规模赋能ToB 外部规模赋能是把内部验证过的 Agent 能力产品化交付给外部客户使用。它不能只是一两个定制项目而是要让交付成本随着客户数量增加而持续下降。外部客户要的不只是“你有大模型”他们要的是效果帮他们省几个人力、提升流程规范性、减少差错率。规模赋能的本质是“复用”场景模板复用、知识库方法论复用、交付流程复用、技术底座复用。如果你做外部项目还是每单从零开发那叫外包不叫赋能。这块业务里最隐蔽的坑是“伪标准化”以为把界面统一就是产品化结果每个客户都有几十个差异化字段集成、权限、审批流互不相同交付团队疲于奔命。真正要标准化的是业务规则抽象和工具协议而不是页面长什么样。外部赋能听起来很热其实拼的是耐力和工程化能力。1.3 为什么必须放在一起分析很多团队把它们分成两条线内部 AI 工具箱由技术中台负责外部产品线由业务事业部负责。结果内部做成了玩具外部做成了外包。其实这两场战争是一场整体战内部闭环是试验场能低成本验证哪些场景真有价值沉淀可复用的 Agent 组件和业务知识外部赋能是放大器能把被验证的能力卖给更多客户反过来倒逼内部组件具备多租户、权限、审计、监控能力。没有内部的真实数据外部方案只是通用聊天机器人没有外部的规模压力内部组件永远不会变得产品化。所以我的建议是无论你先打哪一仗都要用一个技术底座、一套方法论来打不能让两套班子各写各的。后面几章我就按这个思路拆开来讲。2. 内部经营闭环从 Demo 到真实收益的全链路2.1 选场景的三个判断标准我们决定内部项目场景时一开始想做大而全的“企业智能助手”后来发现完全推不动。公司里几百个系统、几千个流程对话式入口解决不了闭环问题。后来把范围缩小才定出三个判断标准第一业务高频最好每天有几十上百次发生第二有明确责任人这个流程的绩效能对应到某个部门第三结果可量化改进后能被财务或运营指标看见。按这个标准销售周报这种“每周一次但老板关心”的场景往往不如“合同初审”这种“每天发生、错误率可计量”的场景有价值。我们当时选了一个试点“合同初审 Agent”。它每天自动读取新合同抽取关键条款、核对法务审查清单输出疑似风险项再推给法务复核。选场景时要记住你要解决的是某个业务团队的真实痛点不是老板的 AI 情怀。如果业务负责人说不出来痛在哪里这个场景基本不会成功。不要用“有点意思”代替“能省多少时间”。2.2 把流程拆成 Agent 能跑的闭环内部闭环的核心是先把业务流程画出来再决定哪些环节用 Agent、哪些用代码规则、哪些保留人工。以合同初审为例原来的流程是商务提交合同 → 法务下载 → 人工看条款 → 在审批系统填意见。Agent 改造后的闭环是商务在合同系统上传 PDF → 事件触发 Agent → Agent 做 OCR 和解析抽取甲方乙方、金额、付款条件、违约责任 → 调用条款风险库进行比对标记风险点 → 生成审查意见草稿 → 推送到法务审批界面 → 法务修改后提交 → 修改差异自动回流到样本库。注意这里我没有让 Agent 直接做审批它只做草稿和推荐因为责任在人。闭环拆解的原则有三条规则稳定且能枚举的放代码函数不要交给模型发挥语义理解类的放 Agent需要追责的必须有人工确认节点。很多内部 Agent 失败就是因为试图把所有事情都塞给大模型最后既没有确定性也没有责任人。流程拆得不细后面每一步都会扯皮。2.3 知识库与工具调用的关键细节做内部 Agent知识库不是“把一堆文档丢进向量库”那么省事。常见问题包括文档版本混乱、权限穿透、更新不及时。我推荐的做法是先清洗知识源每个知识条目带版本、生效日期、责任人然后按业务域切分一个场景一个索引不要全局混合检索最后在 RAG 上层做权限过滤比如销售只能调到销售制度不能调到 HR 薪酬。这一层不做后面一旦出问题往往是权限事故。工具调用同样要有统一协议。Agent 对接 ERP、CRM、OA 时需要一个工具网关把内部 API 封装成统一的 function schema并做好鉴权、限流、审计。一个很实用的经验校验类操作不要让 Agent 直接写 SQL 或调用高风险接口而是由网关里预置的代码函数执行。Agent 只负责说清楚“我要查什么”具体查法由函数决定。这样能把“模型幻觉”和“错误操作”隔离开。知识库和工具网关是内部闭环的两根柱子任何一根不稳整个闭环都会散。2.4 数据回流与人工审核的闭环设计内部经营闭环最容易被忽略的一环是数据回流。很多项目上线后Agent 每天产出结果人工修改后结果就没了Agent 永远不知道自己是对是错。我会在技术架构里强制加入回捞机制人工在系统里对 Agent 输出做了任何修改都要把原始输出、修改后内容、操作人、修改原因存下来。每周末跑一次“一次通过率”和“编辑距离”看哪些场景模型输出和人工结果差得远再针对性地调 prompt、加 few-shot、修知识库。闭环率是北极星指标Agent 的产出在无人干预下被业务方直接采纳的比例。一开始不要追求 100%80% 以下是正常的但必须能看到每周环比提升。另一个指标是人工介入率曲线下降说明 Agent 在学会真实规则。这样闭环才能转起来数据 → 评估 → 优化 → 再上线而不是上线即结束。内部项目真正的资产不是模型而是这套反馈回路里积累下来的业务对齐数据。3. ToB 外部规模赋能把能力变成可交付的生意3.1 从内部方案到产品的四个跨越从内部方案到能外部交付中间不是复制粘贴而是四个跨越场景抽象、配置化、交付物标准化、运维可观测。场景抽象是把你内部那个很具体的流程变成一套可以描述的流程骨架比如内部“合同初审”抽象成“文档审阅 Agent 模板”字段、触发、审核人都变成可配置。配置化意味着不能每来一个客户就改代码至少要在配置中心里改阈值、改审查项、改知识库范围。交付物标准化是指每个项目交付给客户的东西要固定需求确认单、知识库清洗报告、效果基线、运维手册、应急预案。运维可观测是指要有日志、指标、告警不是说内部一个人看得懂就行而是客户侧的实施人员也能看懂。这四个跨越里最慢的是场景抽象因为你要把大量业务规则归纳成模板而不是做炫酷页面。外部客户看到的界面差不多但背后能不能配置决定了你能不能规模化。3.2 多租户与私有化部署怎么取舍做外部项目时第一个商务和技术问题就是部署形态。我们遇到的情况是中小客户愿意用 SaaS但会问数据放在哪里大客户基本要求私有化。SaaS 多租户的关键是租户隔离不只是数据库隔离还包括模型调用通道、向量索引、Prompt 配置、知识库版本。私有化部署的关键则是版本升级和远程运维否则交付完一个版本客户用半年后遇到问题你连日志都拿不到。我的建议是最底层做成“同一套引擎两种发行模式”。引擎内部统一支持单租户模式和多租户模式部署时通过配置打开对应开关不要为外部客户重新写一个系统。私有化交付要内置服务心跳和升级包机制让客户 IT 部门可以一键拉取新版本。这既是技术问题也是商务问题交付成本控制不住外部赋能永远做不成规模化生意。选型时别先想技术炫不炫先想你打算卖多少钱、多少人实施。3.3 规模化交付的标准化方法真正让外部交付产生规模效应的是“乐高式交付”把 Agent 能力拆成标准积木。我们内部沉淀了十几个标准积木文档解析、敏感信息脱敏、条款比对、摘要生成、流程推荐、工单分类、报表解释。每个积木都有输入输出 schema、默认提示词、效果基线、已知边界。接客户时先用需求调研问卷把客户场景映射到积木组合而不是启动研发。交付节奏控制在 6 到 8 周第 1 周业务调研与数据采样第 2 周数据接入和清洗第 3 到 4 周积木编排与配置第 5 到 6 周试运行和人机协同第 7 到 8 周验收与交接。标准化运营的核心是“配置项驱动代码”所有客户差异尽量留在配置层包括知识库范围、审批角色、规则阈值、输出格式。如果客户要求改算法或新增接口要额外走变更评估不能默认包含在首期交付里。这样毛利才可控。3.4 让外部场景反哺内部平台外部项目的价值不只是赚交付费而是能给内部平台带来新需求。比如在外部项目里我们发现很多客户的审批系统很碎片没有一个统一的“工单事件源”于是我们把内部工具网关抽成了一个标准事件适配器后来发现很多客户要求审计日志保留三年以上又把它做成平台的默认能力。反哺的前提是有一个“平台产品委员会”来筛选外部需求不然每个客户提两个要求平台都会被定制需求淹没。我给团队的规则是一类需求被两个以上外部客户提到才进入平台候选只提到一次的先用配置或插件实现不污染核心代码。同时内部经营闭环的运营数据也要输出给产品团队作为“开箱即用基线”让外部客户看到这个 Agent 在类似流程里大概能达到什么效果。内外两场战争如果能形成这样互相喂养的关系整个盘子才会越滚越稳。4. 实操过程与关键环节实现4.1 一套引擎两种形态的架构落地示例这里给出一个我实际会用的最小架构底座是 Agent Workflow Engine它不关心客户是谁只负责执行有向无环图式的任务流。引擎之上分两层内部模式与外部模式。内部模式走企业 SSO知识库权限跟组织架构绑定模型调用走企业私有网关外部模式走租户账号体系知识库按租户隔离模型调用走统一网关加租户计费。核心配置可以用 YAML 描述agent: id: contract-review-v1 trigger: type: webhook source: contract_system path: /api/v1/contract/new nodes: - id: parse_doc type: tool tool: document_parser params: ocr: true field_extract: [party_a, party_b, amount, payment, liability] - id: check_clauses type: tool tool: clause_risk_detector params: risk_rules: config/risk_rules.yaml mode: suggest - id: generate_draft type: llm prompt_template: prompt/contract_review_v3.md temperature: 0.1 - id: notify_reviewer type: tool tool: approval_system params: action: create_task manual_check: true这段配置说明了一件事流程里只有 generate_draft 是模型节点其他都是可校验的工具节点。确定性逻辑用工具不确定性语义用 LLM这是内部和外部都能稳妥跑起来的核心原则。部署形态则通过配置文件切换mode: type: multi_tenant # internal / multi_tenant / single_tenant tenant_resolver: header_tenant vector_store: isolation: per_tenant_index这个架构的好处是内部跑三个月沉淀出的每个积木都能直接搬到外部项目里。不用做两套代码只需要把配置切换一下。很多人低估了配置化的价值结果被客户需求追着跑。4.2 内部闭环的指标设计与复盘实操里我会给内部经营闭环配三个指标有效闭环率、单次处理时长、人工修正距离。举个例子一个合同初审 Agent 上线前法务每人每天要看 50 份合同平均每份 15 分钟其中 60% 是重复性审查。上线后Agent 先做初筛和草稿法务每份只用 5 分钟单份节省 10 分钟50 份就节省 500 分钟。如果同时统计修正距离会发现法务常常会把“建议关注”的条款删除说明 Agent 提示词太保守于是调低风险阈值。再说有效闭环率初始可能是 55% 左右随着 few-shot 样本积累到第二轮会变成 73%。这个复盘需要每周固定时间做不要等月度。每一版改动都要和上周样本做回归避免“修好 A 场景、让 B 场景变差”。这些指标不是用来汇报给老板看而是告诉你下一步动哪里。如果只看“回答满意度”你根本不知道优化方向只有看“闭环修正距离”你才能知道模型错在哪。这是我踩了许久才明白的Agent 项目需要的是运营思维不是模型思维。4.3 外部项目的交付流程示例外部交付我不建议一上来就全场铺开而是找一个“冷启动单元”客户某个分/子公司或者某个单一流程。我们一个典型外部项目是给某软件公司做“客服工单分诊 Agent”。流程按 8 周走第 1 周需求调研并抽取 1000 条真实工单第 2 周清洗工单数据建立分类标签体系第 3 周配置工具网关接通客服系统和知识库第 4 周编排摘要、分类、推荐答案三个积木并设定“建议模式”而非“自动回复”第 5 周试运行并收集客服修正动作第 6 周分析修正日志调整分类规则第 7 周验收测试输出效果报告第 8 周交接运维。这里关键不是用了什么大模型而是每个里程碑都有明确的验收标准第 4 周是“人工确认率低于 40%”第 6 周是“分诊准确率超过 90%”做不到就加迭代周不硬上线。外部交付的负责人要敢叫停否则上线后客户每天看到错误结果信任崩塌就再难修复。交付边界看着是在管理客户其实是在保护你自己团队的交付质量和口碑。4.4 两个战场的资源协调与节奏控制两场战争同时打最大的瓶颈不是模型是团队时间和知识复用。我的做法是分层平台组负责引擎和积木归中台内部运营组负责把内部业务流程跑成样板外部交付组负责跑项目交付。内部运营组和外部交付组独立排期但每周共用一次“场景评审会”。内部组发现的场景缺陷必须沉淀到平台组外部组引入的新需求先由平台组判断能否沉淀进积木库。这里要警惕抢资源外部项目有合同 Deadline容易把平台组的人临时拉去救火导致内部闭环停滞。我定的原则是平台组最多投入 30% 人力到具体项目剩下 70% 必须留在引擎建设内部样板项目永远作为外部方案的“可参观案例”存在。一旦内部样板停滞外部销售的信任基础也会动摇所以两场战争的节奏必须绑在一起看而不是各打各的。5. 常见问题与排查技巧实录5.1 内部落地见不到效果的六个常见坑经验里内部项目“上线即失败”多半是这六个坑第一场景不够刚使用频率低运营同学一周用一次第二数据没打通Agent 只能凭文档回答不能查业务系统第三知识库没维护版本错乱模型给出去年的制度第四流程里有“责任真空”Agent 做了决定但没人敢签字于是干脆不用第五没有反馈通道人工修正结果没有回流模型永远不进步第六考核指标错位只看“调用次数”不看“闭环率”。排查方法也很朴素每周找业务操作员聊十五分钟看他们实际操作时在哪一步放弃。Agent 落地不是算法题是流程题和组织题。我见过很多团队把精力放在换更大的模型上结果问题出在对方 IT 不开放接口。先解决数据源和责任人再谈模型优化。这个顺序反过来项目大概率烂尾。5.2 外部交付里最棘手的三个问题外部交付我最头疼的三个问题客户说不清需求、客户数据质量差、定制化需求无限膨胀。客户说“我要一个智能客服”可以是一堆预设按钮也可以是多轮对话你要在第一周用问卷和示例数据把场景迫到具体最好拿客户真实工单给模型跑一版让客户看效果再改。数据质量差带来的是“垃圾进垃圾出”常见字段缺失、格式混乱、术语不一致建议在合同中约定“客户负责数据清洗或购买数据清洗包”而不是默认全包。定制化膨胀的解法是“配置层给边界”在需求确认单里写明交付包含的积木和配置项新增需求走变更单单独报价。不要因为客户是甲方就免费答应一旦免费后面所有需求都会变成免费。守住交付边界ToB 生意才活得下去。我也犯过“想做大而全平台”的错最后发现外部项目越克制越容易结项口碑越好。5.3 问题排查速查表我整理过一张内部排查表很实用。遇到问题先按表查不要一上来就怀疑模型。症状可能原因优先排查动作Agent 答非所问检索召回不匹配 / 提示词歧义查 RAG 召回的 Top5 内容用数据集测试工具调用报错参数格式不符 / 权限不足打开工具网关日志看 function calling 入参输出格式不稳定prompt 约束不够 / 模型温度偏高输出 schema 改为强制 JSON 校验降低 temperature人工介入率不降场景规则变化 / 模型未反映新知识对比人工修正与模型输出的 diff更新 few-shot外部客户反馈效果差知识库样本不足 / 数据分布不同做数据抽样覆盖度分析补客户语料私有化部署升级失败版本依赖冲突 / 数据库迁移脚本错误先做空环境升级演练再上生产这张表的最大价值是让人别慌。排查的原则是先看数据链路再看模型最后看 prompt。很多问题其实是数据管线问题不是模型不行。我见过团队花了三周调 prompt最后发现是上游字段映射错了。这样的教训多一次都嫌多。5.4 我做这几波项目攒下的几个习惯最后分享几条很朴素但是救过命的习惯。第一所有 Prompt 必须进 Git和代码一起评审、一起回滚。第二所有 Agent 输出先走“建议模式”再走“自动模式”至少观察两到四周。第三知识库切分不要用固定长度要按章节标题和业务实体切能显著减少检索噪音。第四给业务方看结果时不要只展示“生成准确”还要展示“节省了多少分钟”钱和时间才是业务方听得懂的语言。第五每个外部项目都要留一个“最小可复现案例包”包含脱敏后的样本、配置、效果基线这是后续规模化的种子。这些习惯不花很多成本但会直接影响内部闭环能不能转起来以及外部赋能能不能持续复制。两场战争看着宏大落到日常其实就是把流程拆干净、把数据收回来、把配置标准化然后一仗一仗耐心打。 只要做过企业 Agent 落地就一定逃不开两场战争内部经营闭环和 ToB 外部规模赋能。这不是指两套技术而是两条完全不同的战场。内部经营闭环是把 Agent 嵌进公司自己的业务流程里让数据、审批、执行、优化形成完整回路ToB 外部规模赋能则要把自己验证过的能力产品化交付给一个个外部客户还要能复制、能规模化。两仗都打过的人会知道这中间隔着一条从“工具好用”到“生意可做”的鸿沟。这篇内容我就按实际踩过的坑把两场战争的全局判断、场景选择、实操路线和常见问题都摊开来讲。1. 先看清全局两场战争两种打法1.1 什么是内部经营闭环内部经营闭环指的是 Agent 在企业的真实业务流程里产生动作并形成结果而不是只输出一段建议。比如财务报销、合同初审、客服工单、经营分析都算。关键点在于“闭环”两个字输入、处理、调用系统、生成结果、人工审批、归档、运营指标回流一步都不能少。Agent 必须“办事”不是“说话”。难点通常不在模型能力而在流程打通、数据权限、责任边界。很多团队内部 Agent 做了半年Demo 很漂亮但业务部门就是不用原因往往是没有形成闭环也没有人真正对结果负责。内部闭环要的是把某一条业务线的效率数字真正改掉比如单笔报销处理时间从 6 分钟降到 2 分钟而不只是“能回答报销政策”。闭环的四个要素我总结为触发要真实、工具要能落库、审核要有人、数据要回流。缺少任何一个Agent 就会退化成聊天机器人。1.2 什么是 ToB 外部规模赋能ToB 外部规模赋能是把内部验证过的 Agent 能力产品化交付给外部客户使用。它不能只是一两个定制项目而是要让交付成本随着客户数量增加而持续下降。外部客户要的不只是“你有大模型”他们要的是效果帮他们省几个人力、提升流程规范性、减少差错率。规模赋能的本质是“复用”场景模板复用、知识库方法论复用、交付流程复用、技术底座复用。如果你做外部项目还是每单从零开发那叫外包不叫赋能。这块业务里最隐蔽的坑是“伪标准化”以为把界面统一就是产品化结果每个客户都有几十个差异化字段集成、权限、审批流互不相同交付团队疲于奔命。真正要标准化的是业务规则抽象和工具协议而不是页面长什么样。外部赋能听起来很热其实拼的是耐力和工程化能力。1.3 为什么必须放在一起分析很多团队把它们分成两条线内部 AI 工具箱由技术中台负责外部产品线由业务事业部负责。结果内部做成了玩具外部做成了外包。其实这两场战争是一场整体战内部闭环是试验场能低成本验证哪些场景真有价值沉淀可复用的 Agent 组件和业务知识外部赋能是放大器能把被验证的能力卖给更多客户反过来倒逼内部组件具备多租户、权限、审计、监控能力。没有内部的真实数据外部方案只是通用聊天机器人没有外部的规模压力内部组件永远不会变得产品化。所以我的建议是无论你先打哪一仗都要用一个技术底座、一套方法论来打不能让两套班子各写各的。后面几章我就按这个思路拆开来讲。2. 内部经营闭环从 Demo 到真实收益的全链路2.1 选场景的三个判断标准我们决定内部项目场景时一开始想做大而全的“企业智能助手”后来发现完全推不动。公司里几百个系统、几千个流程对话式入口解决不了闭环问题。后来把范围缩小才定出三个判断标准第一业务高频最好每天有几十上百次发生第二有明确责任人这个流程的绩效能对应到某个部门第三结果可量化改进后能被财务或运营指标看见。按这个标准销售周报这种“每周一次但老板关心”的场景往往不如“合同初审”这种“每天发生、错误率可计量”的场景有价值。我们当时选了一个试点“合同初审 Agent”。它每天自动读取新合同抽取关键条款、核对法务审查清单输出疑似风险项再推给法务复核。选场景时要记住你要解决的是某个业务团队的真实痛点不是老板的 AI 情怀。如果业务负责人说不出来痛在哪里这个场景基本不会成功。不要用“有点意思”代替“能省多少时间”。2.2 把流程拆成 Agent 能跑的闭环内部闭环的核心是先把业务流程画出来再决定哪些环节用 Agent、哪些用代码规则、哪些保留人工。以合同初审为例原来的流程是商务提交合同 → 法务下载 → 人工看条款 → 在审批系统填意见。Agent 改造后的闭环是商务在合同系统上传 PDF → 事件触发 Agent → Agent 做 OCR 和解析抽取甲方乙方、金额、付款条件、违约责任 → 调用条款风险库进行比对标记风险点 → 生成审查意见草稿 → 推送到法务审批界面 → 法务修改后提交 → 修改差异自动回流到样本库。注意这里我没有让 Agent 直接做审批它只做草稿和推荐因为责任在人。闭环拆解的原则有三条规则稳定且能枚举的放代码函数不要交给模型发挥语义理解类的放 Agent需要追责的必须有人工确认节点。很多内部 Agent 失败就是因为试图把所有事情都塞给大模型最后既没有确定性也没有责任人。流程拆得不细后面每一步都会扯皮。2.3 知识库与工具调用的关键细节做内部 Agent知识库不是“把一堆文档丢进向量库”那么省事。常见问题包括文档版本混乱、权限穿透、更新不及时。我推荐的做法是先清洗知识源每个知识条目带版本、生效日期、责任人然后按业务域切分一个场景一个索引不要全局混合检索最后在 RAG 上层做权限过滤比如销售只能调到销售制度不能调到 HR 薪酬。这一层不做后面一旦出问题往往是权限事故。工具调用同样要有统一协议。Agent 对接 ERP、CRM、OA 时需要一个工具网关把内部 API 封装成统一的 function schema并做好鉴权、限流、审计。一个很实用的经验校验类操作不要让 Agent 直接写 SQL 或调用高风险接口而是由网关里预置的代码函数执行。Agent 只负责说清楚“我要查什么”具体查法由函数决定。这样能把“模型幻觉”和“错误操作”隔离开。知识库和工具网关是内部闭环的两根柱子任何一根不稳整个闭环都会散。2.4 数据回流与人工审核的闭环设计内部经营闭环最容易被忽略的一环是数据回流。很多项目上线后Agent 每天产出结果人工修改后结果就没了Agent 永远不知道自己是对是错。我会在技术架构里强制加入回捞机制人工在系统里对 Agent 输出做了任何修改都要把原始输出、修改后内容、操作人、修改原因存下来。每周末跑一次“一次通过率”和“编辑距离”看哪些场景模型输出和人工结果差得远再针对性地调 prompt、加 few-shot、修知识库。闭环率是北极星指标Agent 的产出在无人干预下被业务方直接采纳的比例。一开始不要追求 100%80% 以下是正常的但必须能看到每周环比提升。另一个指标是人工介入率曲线下降说明 Agent 在学会真实规则。这样闭环才能转起来数据 → 评估 → 优化 → 再上线而不是上线即结束。内部项目真正的资产不是模型而是这套反馈回路里积累下来的业务对齐数据。3. ToB 外部规模赋能把能力变成可交付的生意3.1 从内部方案到产品的四个跨越从内部方案到能外部交付中间不是复制粘贴而是四个跨越场景抽象、配置化、交付物标准化、运维可观测。场景抽象是把你内部那个很具体的流程变成一套可以描述的流程骨架比如内部“合同初审”抽象成“文档审阅 Agent 模板”字段、触发、审核人都变成可配置。配置化意味着不能每来一个客户就改代码至少要在配置中心里改阈值、改审查项、改知识库范围。交付物标准化是指每个项目交付给客户的东西要固定需求确认单、知识库清洗报告、效果基线、运维手册、应急预案。运维可观测是指要有日志、指标、告警不是说内部一个人看得懂就行而是客户侧的实施人员也能看懂。这四个跨越里最慢的是场景抽象因为你要把大量业务规则归纳成模板而不是做炫酷页面。外部客户看到的界面差不多但背后能不能配置决定了你能不能规模化。3.2 多租户与私有化部署怎么取舍做外部项目时第一个商务和技术问题就是部署形态。我们遇到的情况是中小客户愿意用 SaaS但会问数据放在哪里大客户基本要求私有化。SaaS 多租户的关键是租户隔离不只是数据库隔离还包括模型调用通道、向量索引、Prompt 配置、知识库版本。私有化部署的关键则是版本升级和远程运维否则交付完一个版本客户用半年后遇到问题你连日志都拿不到。我的建议是最底层做成“同一套引擎两种发行模式”。引擎内部统一支持单租户模式和多租户模式部署时通过配置打开对应开关不要为外部客户重新写一个系统。私有化交付要内置服务心跳和升级包机制让客户 IT 部门可以一键拉取新版本。这既是技术问题也是商务问题交付成本控制不住外部赋能永远做不成规模化生意。选型时别先想技术炫不炫先想你打算卖多少钱、多少人实施。3.3 规模化交付的标准化方法真正让外部交付产生规模效应的是“乐高式交付”把 Agent 能力拆成标准积木。我们内部沉淀了十几个标准积木文档解析、敏感信息脱敏、条款比对、摘要生成、流程推荐、工单分类、报表解释。每个积木都有输入输出 schema、默认提示词、效果基线、已知边界。接客户时先用需求调研问卷把客户场景映射到积木组合而不是启动研发。交付节奏控制在 6 到 8 周第 1 周业务调研与数据采样第 2 周数据接入和清洗第 3 到 4 周积木编排与配置第 5 到 6 周试运行和人机协同第 7 到 8 周验收与交接。标准化运营的核心是“配置项驱动代码”所有客户差异尽量留在配置层包括知识库范围、审批角色、规则阈值、输出格式。如果客户要求改算法或新增接口要额外走变更评估不能默认包含在首期交付里。这样毛利才可控。3.4 让外部场景反哺内部平台外部项目的价值不只是赚交付费而是能给内部平台带来新需求。比如在外部项目里我们发现很多客户的审批系统很碎片没有一个统一的“工单事件源”于是我们把内部工具网关抽成了一个标准事件适配器后来发现很多客户要求审计日志保留三年以上又把它做成平台的默认能力。反哺的前提是有一个“平台产品委员会”来筛选外部需求不然每个客户提两个要求平台都会被定制需求淹没。我给团队的规则是一类需求被两个以上外部客户提到才进入平台候选只提到一次的先用配置或插件实现不污染核心代码。同时内部经营闭环的运营数据也要输出给产品团队作为“开箱即用基线”让外部客户看到这个 Agent 在类似流程里大概能达到什么效果。内外两场战争如果能形成这样互相喂养的关系整个盘子才会越滚越稳。4. 实操过程与关键环节实现4.1 一套引擎两种形态的架构落地示例这里给出一个我实际会用的最小架构底座是 Agent Workflow Engine它不关心客户是谁只负责执行有向无环图式的任务流。引擎之上分两层内部模式与外部模式。内部模式走企业 SSO知识库权限跟组织架构绑定模型调用走企业私有网关外部模式走租户账号体系知识库按租户隔离模型调用走统一网关加租户计费。核心配置可以用 YAML 描述agent: id: contract-review-v1 trigger: type: webhook source: contract_system path: /api/v1/contract/new nodes: - id: parse_doc type: tool tool: document_parser params: ocr: true field_extract: [party_a, party_b, amount, payment, liability] - id: check_clauses type: tool tool: clause_risk_detector params: risk_rules: config/risk_rules.yaml mode: suggest - id: generate_draft type: llm prompt_template: prompt/contract_review_v3.md temperature: 0.1 - id: notify_reviewer type: tool tool: approval_system params: action: create_task manual_check: true这段配置说明了一件事流程里只有 generate_draft 是模型节点其他都是可校验的工具节点。确定性逻辑用工具不确定性语义用 LLM这是内部和外部都能稳妥跑起来的核心原则。部署形态则通过配置文件切换mode: type: multi_tenant # internal / multi_tenant / single_tenant tenant_resolver: header_tenant vector_store: isolation: per_tenant_index这个架构的好处是内部跑三个月沉淀出的每个积木都能直接搬到外部项目里。不用做两套代码只需要把配置切换一下。很多人低估了配置化的价值结果被客户需求追着跑。4.2 内部闭环的指标设计与复盘实操里我会给内部经营闭环配三个指标有效闭环率、单次处理时长、人工修正距离。举个例子一个合同初审 Agent 上线前法务每人每天要看 50 份合同平均每份 15 分钟其中 60% 是重复性审查。上线后Agent 先做初筛和草稿法务每份只用 5 分钟单份节省 10 分钟50 份就节省 500 分钟。如果同时统计修正距离会发现法务常常会把“建议关注”的条款删除说明 Agent 提示词太保守于是调低风险阈值。再说有效闭环率初始可能是 55% 左右随着 few-shot 样本积累到第二轮会变成 73%。这个复盘需要每周固定时间做不要等月度。每一版改动都要和上周样本做回归避免“修好 A 场景、让 B 场景变差”。这些指标不是用来汇报给老板看而是告诉你下一步动哪里。如果只看“回答满意度”你根本不知道优化方向只有看“闭环修正距离”你才能知道模型错在哪。这是我踩了许久才明白的Agent 项目需要的是运营思维不是模型思维。4.3 外部项目的交付流程示例外部交付我不建议一上来就全场铺开而是找一个“冷启动单元”客户某个分/子公司或者某个单一流程。我们一个典型外部项目是给某软件公司做“客服工单分诊 Agent”。流程按 8 周走第 1 周需求调研并抽取 1000 条真实工单第 2 周清洗工单数据建立分类标签体系第 3 周配置工具网关接通客服系统和知识库第 4 周编排摘要、分类、推荐答案三个积木并设定“建议模式”而非“自动回复”第 5 周试运行并收集客服修正动作第 6 周分析修正日志调整分类规则第 7 周验收测试输出效果报告第 8 周交接运维。这里关键不是用了什么大模型而是每个里程碑都有明确的验收标准第 4 周是“人工确认率低于 40%”第 6 周是“分诊准确率超过 90%”做不到就加迭代周不硬上线。外部交付的负责人要敢叫停否则上线后客户每天看到错误结果信任崩塌就再难修复。交付边界看着是在管理客户其实是在保护你自己团队的交付质量和口碑。4.4 两个战场的资源协调与节奏控制两场战争同时打最大的瓶颈不是模型是团队时间和知识复用。我的做法是分层平台组负责引擎和积木归中台内部运营组负责把内部业务流程跑成样板外部交付组负责跑项目交付。内部运营组和外部交付组独立排期但每周共用一次“场景评审会”。内部组发现的场景缺陷必须沉淀到平台组外部组引入的新需求先由平台组判断能否沉淀进积木库。这里要警惕抢资源外部项目有合同 Deadline容易把平台组的人临时拉去救火导致内部闭环停滞。我定的原则是平台组最多投入 30% 人力到具体项目剩下 70% 必须留在引擎建设内部样板项目永远作为外部方案的“可参观案例”存在。一旦内部样板停滞外部销售的信任基础也会动摇所以两场战争的节奏必须绑在一起看而不是各打各的。5. 常见问题与排查技巧实录5.1 内部落地见不到效果的六个常见坑经验里内部项目“上线即失败”多半是这六个坑第一场景不够刚使用频率低运营同学一周用一次第二数据没打通Agent 只能凭文档回答不能查业务系统第三知识库没维护版本错乱模型给出去年的制度第四流程里有“责任真空”Agent 做了决定但没人敢签字于是干脆不用第五没有反馈通道人工修正结果没有回流模型永远不进步第六考核指标错位只看“调用次数”不看“闭环率”。排查方法也很朴素每周找业务操作员聊十五分钟看他们实际操作时在哪一步放弃。Agent 落地不是算法题是流程题和组织题。我见过很多团队把精力放在换更大的模型上结果问题出在对方 IT 不开放接口。先解决数据源和责任人再谈模型优化。这个顺序反过来项目大概率烂尾。5.2 外部交付里最棘手的三个问题外部交付我最头疼的三个问题客户说不清需求、客户数据质量差、定制化需求无限膨胀。客户说“我要一个智能客服”可以是一堆预设按钮也可以是多轮对话你要在第一周用问卷和示例数据把场景迫到具体最好拿客户真实工单给模型跑一版让客户看效果再改。数据质量差带来的是“垃圾进垃圾出”常见字段缺失、格式混乱、术语不一致建议在合同中约定“客户负责数据清洗或购买数据清洗包”而不是默认全包。定制化膨胀的解法是“配置层给边界”在需求确认单里写明交付包含的积木和配置项新增需求走变更单单独报价。不要因为客户是甲方就免费答应一旦免费后面所有需求都会变成免费。守住交付边界ToB 生意才活得下去。我也犯过“想做大而全平台”的错最后发现外部项目越克制越容易结项口碑越好。5.3 问题排查速查表我整理过一张内部排查表很实用。遇到问题先按表查不要一上来就怀疑模型。症状可能原因优先排查动作Agent 答非所问检索召回不匹配 / 提示词歧义查 RAG 召回的 Top5 内容用数据集测试工具调用报错参数格式不符 / 权限不足打开工具网关日志看 function calling 入参输出格式不稳定prompt 约束不够 / 模型温度偏高输出 schema 改为强制 JSON 校验降低 temperature人工介入率不降场景规则变化 / 模型未反映新知识对比人工修正与模型输出的 diff更新 few-shot外部客户反馈效果差知识库样本不足 / 数据分布不同做数据抽样覆盖度分析补客户语料私有化部署升级失败版本依赖冲突 / 数据库迁移脚本错误先做空环境升级演练再上生产这张表的最大价值是让人别慌。排查的原则是先看数据链路再看模型最后看 prompt。很多问题其实是数据管线问题不是模型不行。我见过团队花了三周调 prompt最后发现是上游字段映射错了。这样的教训多一次都嫌多。5.4 我做这几波项目攒下的几个习惯最后分享几条很朴素但是救过命的习惯。第一所有 Prompt 必须进 Git和代码一起评审、一起回滚。第二所有 Agent 输出先走“建议模式”再走“自动模式”至少观察两到四周。第三知识库切分不要用固定长度要按章节标题和业务实体切能显著减少检索噪音。第四给业务方看结果时不要只展示“生成准确”还要展示“节省了多少分钟”钱和时间才是业务方听得懂的语言。第五每个外部项目都要留一个“最小可复现案例包”包含脱敏后的样本、配置、效果基线这是后续规模化的种子。这些习惯不花很多成本但会直接影响内部闭环能不能转起来以及外部赋能能不能持续复制。两场战争看着宏大落到日常其实就是把流程拆干净、把数据收回来、把配置标准化然后一仗一仗耐心打。