咨询｜你的 Agent 为什么死在生产：写给「帮甲方落地 Agent」的公司

过去一年，大家都有类似体验： POC 做得热热闹闹，Demo 演得甲方连连点头，一进生产环境，Agent 就开始各种「迷路、犯傻、乱操作」，最后项目悄无声息地被雪藏——不是模型不行，而是系统没准备好。

Josh Schultz（BlackArc AI 创始人）在一篇关于企业 Agent 落地的文章里，把这个问题讲得非常透：Agent 的失败，本质上是系统工程和组织设计的问题，而不是 prompt 和框架的问题。

来源：X

对我们这类「帮企业落 Agent」的公司来说，有一个重要的心态转变： 你交付的不是一个「聪明的 Agent」，而是一套「能在真实业务系统里长期活下去的 Agentic Workflow」。Agent 是其中一块「大脑」，但真正决定成败的是：你怎么理解业务系统、怎么设计反馈、怎么控制边界、怎么与原有 IT 系统一起工作。

下面这篇文章分四部分展开：

1. 企业落 Agent 需要遵循的几个关键原则
2. 一个可落地的 LLM Agent 方法论：从系统映射到影子模式
3. 我们给读者准备好的 Agent 知识库：波士顿、麦肯锡等案例 PDF 可用智能体问答获取
4. 目前对中国企业最合适的几类 Agent 场景，以及建议采用的技术栈路径

一、企业落 Agent 的四个原则：先当系统工程师，再当 AI 工程师

把企业当「复杂系统」，而不是当「一堆流程」。Schultz 的核心观点之一是：大多数企业 Agent 项目死在「从 Demo 到生产」，原因不是模型不够强，而是我们把企业想得太简单。 在 Demo 环节，我们只是在一个切出来的小 sandbox 里让 Agent 正常运转；一旦进入真实生产，就要面对跨系统耦合、长周期反馈、多人协同、异常路径，这时候问题不是「Agent 会不会写 SQL」，而是「它做的这个决策，会不会在别的地方引发连锁反应」。

这也是他用 2010 年美股闪崩做类比的原因：每一个算法在本地都是「理性」的，但整个系统拼在一起，就会产生没人预料到的灾难性行为。 Agent 在企业里也是同样的角色——你必须把整个系统画出来，再决定把 Agent 放在哪、给它多大权力。

在写第一行 Agent 代码前，先做「系统映射」。 BlackArc 的做法，是在任何一个 Agent 项目开始前，先花 2–4 周做系统映射：走流程、画连接、拆决策。 他们会和真正干活的一线员工一起，把一个 workflow 从触发到输出走一遍，记录每一个决策点、每一次跨系统取数、每一条异常处理路径，然后再去画「谁影响谁、谁依赖谁」。

这里有三个关键动作：

• 走流程：不问写流程文档的人，问每天真的点系统、回邮件、改订单的人。

• 画耦合：哪些步骤共享同一份数据，哪些是其它流程的上游或下游，这决定了 Agent 出错时影响范围有多大。

• 拆决策：把决策分成「规则型」（可以清晰写成 if-else）和「判断型」（需要经验、博弈和权衡），前者适合给 Agent，后者要么先保留在人工，要么在有足够数据后再逐步迁移。

很多项目是反过来的：先招一个大模型团队，先选一个框架，然后在一个模糊的流程上「试着堆功能」。这几乎保证了项目会在生产阶段翻车。

明确四种数据层，别把所有东西糊成一个「Prompt Soup」。 Schultz 提出，在企业级 Agent 流程里，至少要区分四种数据层：

1. 系统记录（System of Record）：ERP、CRM、财务系统等，是唯一可信的业务事实来源。

2. 业务规则（Business Rules）：决策逻辑、阈值、审批链、例外处理等。

3. 原始输入（Raw Intake）：发票、邮件、合同、客服聊天记录等。

4. Agent 记忆（Agent Memory）：过去做过的决策、被纠正的错误、学到的模式。

如果你把这些东西都塞进一个「大上下文 + 一个 prompt」里，短期 Demo 看起来很爽，长期维护就会灾难——业务要改规则、合规要收紧权限、IT 要迁移系统，每改一次都要去改 prompt 和代码，风险巨大。 反过来，如果这些层是清晰分离的，你可以让业务同事直接维护业务规则，让工程专注在连接系统上，让模型团队专注在推理质量上。

在现有系统上构建，而不是绕过现有系统。 另一个很现实的原则：不要幻想用一个新 Agent 平台「推翻」甲方原有 IT。企业已经在 SAP、用友、金蝶、Salesforce、钉钉、企业微信等系统上投入了巨大的成本和组织惯性，你做 Agent，要做的是「贴在现有系统之上」，而不是「替代现有系统」。

在北美的实践里，BlackArc 的做法是：优先通过 API、事件流（如 Kafka）、和「computer-use」能力，去驱动现有的 ERP/MRP/CRM，而不是要求客户换系统或重新搭建数据仓。 对中国企业来说，这点同样重要——你的方案越是尊重现有 IT 资产和权限体系，就越容易通过信息部、风控和合规这一关。

二、一个可落地的 LLM Agent 方法论：从系统映射到影子模式

基于上述原则，我们可以勾勒出一套适合中国企业、也适合「帮甲方落地」公司的 LLM Agent 方法论，大致分为五步，每一步有很明确的交付物。

第一步：系统映射（System Mapping）目标不是「画一张完美的流程图」，而是识别出这条业务线上真正关键的决策点和耦合点。 建议做几件事：

• 选一个具体的 end-to-end 业务流程（比如：供应商入驻、应收账款催收、合同审核、订单异常处理）。

• 和一线业务人员一起，从触发事件开始一路走到终态，记录每一步动作背后的「为什么」。

• 标注每一步依赖的系统（ERP、CRM、邮件、Excel、钉钉群等）和数据字段。

交付物：一份「流程拆解文档」，包含步骤列表、系统依赖、输入输出、异常分支。

第二步：决策拆分（Decision Decomposition）在系统映射基础上，对每一个涉及判断的步骤做拆分：这是规则型还是判断型？

规则型决策：比如「金额小于 2 万、同一供应商近 12 个月无逾期，就自动通过」，可以清晰地写成 rule engine 或结构化配置。

判断型决策：比如「这家供应商的持续供货风险是不是太高」「这封投诉邮件需不需要升级到区域负责人」，需要经验和权衡。

在落地策略上，可以采用「规则优先、判断渐进」：先把规则型决策交给 Agent 驱动，判断型决策先保留在人类，但由 Agent 完成「归集信息 -> 给出建议 -> 由人拍板」的流程，这样既能提升效率，又能为未来完全自动化积累监督数据。

“

当然这里如何抓取决策的数据也是一个大学问。我们给一些机构建议过，需要将决策的数据也用来做数据闭环，这样agents未来才能有自主决策的能力。

交付物：一个「决策列表」，每个决策点都标明类型、可自动化程度、风险级别。

第三步：Agent 架构设计（Brain / Hands / Memory / Guardrails）结合 Anthropic Managed Agents 等架构经验，我们建议把企业 Agent 拆成四个部分：

Brain：调用大模型的控制层，负责理解任务、拆解步骤、调用工具，不直接接数据库。

Hands：一层可控的「执行沙盒」，通过 API 或「电脑操作」去访问 ERP/CRM/内部系统，做到「可审计、可回滚」。

Memory：一份结构化的「会话 + 决策日志」，记录 Agent 每一次观察、判断、动作和人类反馈，用于审计和持续学习。

Guardrails：权限边界、合规规则、黑名单操作、额度限制等，这些最好以配置形式存储，而不是写死在 prompt 或代码里。

“

Memory之前我们写的挺多的，大家感兴趣可以后台和智能体问答。

交付物：一份「Agent 架构说明」，清楚列出每种数据在哪里、谁有权限改。

第四步：影子模式（Shadow Mode）与 HITL（人类在环）BlackArc 在文章里强调：不要一上来就全量放权，而是先跑一段时间的「影子模式」，并用数据衡量 Agent 和人的决策一致度。

一个典型路线是：

影子模式：Agent 全量跑流程，但不真正执行，只在后台给出「它会怎么做」，并与人类实际操作对比。

设定门槛：当一致性达到例如 95% 时，再在低风险场景下开启「有监督生产」，即 Agent 执行，但关键操作需人工点确认。

建立反馈闭环：每一次人工「拒绝或修正 Agent 决策」，都作为训练样本写入 Memory 层，用于后续微调或规则优化。

“

这也是为什么很多时候养龙虾或者养一个Agent其实是很花时间的，并不是大家看到的那样，能自动执行很多的任务。

交付物：影子模式评估报告（一致度、错误类型、风险分析）和 HITL 反馈日志结构。

第五步：分阶段扩展与持续运营当一个流程、一个区域、一个业务单元跑稳后，再逐步复制到更多范围，避免「一刀切」上线。 同时，对 Agent 建立真正的「运维」能力：监控、告警、版本控制、A/B 实验，而不是「交付完就算结束」。

这部分就不展开写，可以单独写一篇「Agent 运维（MLOps + AgentOps）」的文章来讲。

在我们自己的公众号里，其实已经写过大量关于波士顿、麦肯锡等咨询公司在 LLM / Agent 上的架构解读和案例分析 PDF。 这些内容单独看都是一篇篇「干货长文」，但在实战中，大家很难在项目节奏里「从头翻一遍 PDF」。

“

感兴趣的欢迎后台对话我们的智能体，获取相关的PDF文档链接；这些内容都是网上公开的，如果大家愿意，也可以自行去网络上通过关键词搜索。

三、今天给中国企业做 LLM Agent，最合适从哪里切入？用什么技术栈？

几个最现实、ROI 比较清晰的 use case

结合海外和中国的实践，目前对中国企业而言，比较适合作为「第一批 Agent 项目」的方向，主要集中在「内部流程自动化 + 知识问答」两大类：

文档和知识类 Agent：面向合约、制度、产品手册、投标文档、内部制度，做精确检索 + 多轮问答 + 草稿生成，服务法务、人力、销售支持等部门。

财务与合规支持 Agent：自动整理发票、对账、初筛异常交易、生成合规报告草稿，由财务/风控人员最终确认，强调「代做准备工作，而不是代替审批」。

客服与售后 Agent：基于历史工单、知识库和 IoT 数据，对常见问题进行自动回复，对复杂工单做「归集信息 + 推荐解决方案」，再交给人工处理。

供应链与采购支持 Agent：在供应商入驻、询价比价、订单异常处理上，先自动整理信息和预判风险，再由采购同事拍板。

内部 Copilot / Coding Agent：帮助内部 IT 和业务开发团队写接口、改脚本、查日志、生成文档，其 ROI 在海外已经非常清晰（如 Cursor 等产品）。

这些场景有几个共性：

1. 数据主要在内部系统和文档里，隐私与合规可控；
2. 决策链条清晰，可以拆分出规则型决策和判断型决策；
3. 有现成人工 baseline，可以快速进入影子模式并对比效果。

避开高风险高政治敏感区：从「收入表底部」切入

Schultz 提醒了一点很有启发：从财报的「收入表底部」开始自动化——优先选那些必要但不直接决定营收的大量重复性工作，例如供应商、发票、合规、内部报告，而不是一上来就挑战「销售策略、定价、客户谈判」等高政治敏感区。

对中国企业尤其如此：很多组织里，谁有权做决策、谁负责对外沟通，是非常敏感的权力结构问题。先在「后端支持型流程」把方法论跑顺，证明安全可靠，再逐步往前台扩展，会更容易得到业务和高层的 buy-in。

技术栈建议：兼顾「中国语境」和「企业约束」

结合国内的监管环境、数据在本地的要求，以及大模型生态的发展，技术栈可以这样考虑：

模型层：优先选用国产大模型（如通义、文心、GLM 等）或企业自建/专有部署的开源模型，以便满足数据本地化与合规要求，同时预留「多模型路由」能力，对复杂推理或代码生成可以接 Frontier 模型（在合规前提下）。

Agent 框架层：在国内已经有不少适配好的 Agent 框架和编排平台，也可以基于 LangChain、LlamaIndex 等自建轻量编排层，再叠加你自己的「Harness 工程」能力（日志、监控、权限、版本控制）。 中国的智能体编排平台有Dify、有Coze、有百度等大厂。

如上图片均来自于官网

系统集成层：重点是对接现有 OA、ERP、CRM、知识库（钉钉、企微、飞书、用友、金蝶、自研系统），建议用清晰的 API 或事件总线来做，而不是写大量定制爬虫或直接连库。

数据与安全层：引入向量数据库做检索（国产或自建）、审计日志系统、权限控制、脱敏和水印，以及必要的安全审计接口，确保 Agent 所有操作都有迹可循。

运维与监控层：接入现有的日志与监控体系（如企业已经在用的 Prometheus、ELK、国产监控平台），为 Agent 建立「错误率、响应时间、覆盖率、人工介入率」等指标面板。

在我们之前的文章里，其实已经拆过 BCG、麦肯锡等咨询公司在 LLM Agent 上的一些架构思路——比如如何分离「大脑、执行、记忆」，如何在项目里引入「AgentOps」，如何度量 Agent 对项目 ROI 的贡献。