企业Agent落地：内部闭环与ToB赋能的两场仗，你打对了吗？

企业里做 Agent 落地，最怕的不是技术选型，而是没搞清楚自己到底在打哪场仗。我见过太多团队把内部提效的 Agent 和对外赋能的 Agent 混在一起做，结果内部流程还没跑通就急着包装成产品卖给客户，最后两边都塌。这两件事看起来都是"让 Agent 帮人干活"，但底层逻辑、技术架构、成功标准完全是两码事。内部经营闭环打的是"确定性"和"深度集成"，ToB 外部规模赋能打的是"通用性"和"多租户隔离"。今天我就把这两场仗拆开讲清楚，包括我在实际项目中踩过的坑、架构设计的取舍、以及多租户和 Prompt 工程里那些文档不会写的细节。

1. 先搞清楚你打的是哪场仗

1.1 内部经营闭环的本质：用 Agent 吃掉确定性流程

内部经营闭环这个词听起来很虚，说白了就是：企业自己用 Agent 来优化自己的业务流程。比如客服工单自动分类、财务报销自动审核、供应链异常自动预警、销售线索自动打分。这些场景有一个共同特征——流程是确定的，数据是私有的，成功标准是可量化的。

我做过一个制造业客户的内部 Agent 项目，需求是"设备故障工单自动派发"。这个场景看起来简单，但拆开看：故障描述来自现场工人用手机拍的文字和语音，需要先做多模态理解；然后要匹配历史维修记录找到相似案例；再根据维修工程师的技能标签、当前工单负载、地理位置做派单决策；最后还要把结果写回 ERP 系统并通知相关人员。整个链路涉及 4 个系统、3 种数据格式、2 个决策模型。

这种场景下，Agent 的价值不在于"通用智能"，而在于把原来需要人工跨系统操作的 15 分钟压缩到 30 秒。你不需要它什么都会，你只需要它在特定流程上比人快、比人稳、不出错。

内部闭环的核心指标就三个：流程耗时降低比例、人工干预率、异常处理准确率。其他都是虚的。

1.2 ToB 外部规模赋能的本质：把能力封装成可复制的产品

ToB 外部规模赋能完全是另一回事。你要把 Agent 能力卖给客户，客户拿回去在自己的业务场景里用。这时候你面对的是：不同客户的业务流程不一样、数据不能混、权限要隔离、SLA 要承诺、出了问题客户会找你。

我参与过一个面向中小电商的客服 Agent 产品，客户数量从 5 家涨到 50 家的过程中，暴露出来的问题几乎全在"多租户"上：A 客户的 Prompt 模板被 B 客户误用了、C 客户的对话数据出现在了 D 客户的训练集里、E 客户要求独立部署但 F 客户要求共享成本。这些问题在内部闭环场景里根本不存在，因为内部只有一个"租户"——你自己。

ToB 产品的核心指标是：客户留存率、单客户边际成本、SLA 达成率、新客户接入周期。技术指标反而排在后面，因为客户不关心你用什么框架，只关心"能不能用、稳不稳、贵不贵"。

1.3 两场仗的对比：一张表看清差异

这张表是我在两次踩坑之后总结的。第一次踩坑是拿内部闭环的思路去做 ToB 产品，把 Prompt 写死在代码里，结果第二个客户接入时发现业务逻辑完全不同，改 Prompt 等于重写。第二次踩坑是拿 ToB 产品的思路去做内部闭环，过度设计多租户和配置化，结果内部流程三个月都没上线，业务方直接失去耐心。

提示：判断你该打哪场仗，问自己一个问题——这个 Agent 是给"一个确定的业务方"用，还是给"多个不确定的客户"用？前者是内部闭环，后者是 ToB 赋能。不要试图用一套架构同时满足两者。

2. 内部闭环的架构设计：深度集成比通用性重要

2.1 为什么内部闭环不需要多租户

很多团队一上来就想着"万一以后要卖给客户呢"，于是把多租户架构提前做进去。我的经验是：内部闭环阶段做多租户，99% 是过度设计。

原因很简单：内部闭环的租户只有一个，就是你自己。你不需要考虑数据隔离，因为所有数据都是公司的；你不需要考虑配置隔离，因为流程是统一的；你不需要考虑权限隔离，因为权限体系公司已经有了。你真正需要的是深度集成——Agent 能不能直接读 ERP 的数据、能不能直接写 CRM 的工单、能不能调用内部的审批流。

我见过一个团队，内部 Agent 项目做了 6 个月，其中 4 个月在搞多租户框架，结果业务方等不及了，直接用 RPA 把流程自动化了。多租户框架最后一行代码都没用上。

内部闭环的架构应该是这样的：

# 内部闭环 Agent 的典型架构（简化版） class InternalAgent: def __init__(self, erp_client, crm_client, knowledge_base): self.erp = erp_client # 直接连内部系统 self.crm = crm_client # 直接连内部系统 self.kb = knowledge_base # 内部知识库 self.prompt = load_prompt("dispatch_v3.txt") # Prompt 可以硬编码 def handle_ticket(self, ticket): # 1. 理解工单 intent = self.understand(ticket) # 2. 查历史案例 similar = self.kb.search(intent) # 3. 决策 decision = self.decide(intent, similar) # 4. 写回系统 self.crm.update(ticket.id, decision) return decision

注意这里没有租户 ID、没有配置中心、没有权限校验层。因为不需要。Prompt 直接读文件，改了就重启，内部系统可以接受。

2.2 数据打通是内部闭环的命门

内部闭环 Agent 的成败，80% 取决于数据能不能打通。我做过一个财务报销 Agent，技术方案很漂亮，但卡在了"发票数据拿不到"——财务系统是 10 年前的老系统，没有 API，数据库是 Oracle 但字段命名是拼音缩写。最后花了 3 周做数据适配层，Agent 本身只写了 1 周。

数据打通的常见障碍：

• 老系统没有 API：只能走数据库直连或文件导出，需要做定时同步
• 字段语义不明确：XMBH到底是"项目编号"还是"项目驳回"？需要找老员工确认
• 数据质量差：同一个客户在三个系统里有三个名字，需要做实体对齐
• 实时性要求：有些流程要求秒级响应，但数据同步是 T+1

我的建议是：先做数据盘点，再做 Agent 设计。把涉及的系统、表、字段、更新频率、数据质量全部列出来，评估打通成本。如果某个系统的打通成本超过 Agent 本身的价值，就考虑用 RPA 模拟人工操作绕过它。

2.3 Prompt 在内部场景可以"过度调优"

内部闭环的一个优势是：你可以针对特定场景把 Prompt 调到极致。因为场景是确定的，你可以收集大量真实案例做 few-shot，可以针对边界情况写详细的规则，可以做多轮迭代。

我做过一个合同审核 Agent，Prompt 迭代了 17 个版本。每个版本都是针对真实审核失败案例做的修正。比如发现模型对"违约金比例超过 30%"的条款识别不准，就在 Prompt 里加一条明确规则；发现模型对"甲方乙方"的指代理解有误，就加一个指代消解的示例。

这种"过度调优"在 ToB 场景是不可行的，因为每个客户的合同模板不一样。但在内部场景，这就是核心竞争力——你的 Prompt 里沉淀了公司多年的业务经验。

注意：内部 Prompt 调优要有版本管理和回归测试。我吃过亏，改了一个 Prompt 修好了 A 场景，结果 B 场景的准确率从 95% 掉到 70%。后来强制要求每次改 Prompt 必须跑一遍回归测试集。

3. ToB 赋能的架构设计：多租户是绕不过去的坎

3.1 多租户的三种隔离级别与选型逻辑

ToB Agent 产品做多租户，首先要选隔离级别。常见的有三种：

我做过的一个客服 Agent 产品，初期用的是共享数据库+租户字段，客户涨到 30 家时出现了性能问题——所有客户的对话数据在一张表里，查询越来越慢。后来改成独立 Schema，每个客户一个 Schema，性能问题解决了，但运维复杂度上来了。

选型逻辑很简单：看客户愿意付多少钱，以及客户对数据隔离的要求有多高。中小客户用共享模式，大客户用独立部署。不要试图用一种模式通吃。

3.2 Prompt 模板化：从"写死"到"可配置"的改造

ToB 场景下，Prompt 不能再写死在代码里。你需要一套 Prompt 模板系统，让每个租户可以配置自己的 Prompt。

我设计的 Prompt 模板系统大概长这样：

class PromptTemplate: def __init__(self, tenant_id, template_name): self.tenant_id = tenant_id self.template_name = template_name self.base_template = load_base_template(template_name) self.tenant_config = load_tenant_config(tenant_id, template_name) def render(self, variables): # 1. 加载基础模板 prompt = self.base_template # 2. 注入租户配置（如公司名称、业务规则、语气风格） prompt = prompt.format(**self.tenant_config) # 3. 注入运行时变量（如用户输入、上下文） prompt = prompt.format(**variables) # 4. 版本记录 log_prompt_version(self.tenant_id, self.template_name, prompt) return prompt

关键设计点：

• 基础模板 + 租户覆盖：基础模板定义通用逻辑，租户可以覆盖特定部分
• 变量注入：把租户特有的信息（公司名、产品名、业务规则）作为变量注入
• 版本管理：每次渲染都记录版本，出问题可以回溯
• 灰度发布：新模板先给 10% 流量，观察效果再全量

这里有个坑：Prompt 模板的变量注入要做转义。我遇到过客户在配置里写了{company_name}，结果被当成变量解析了，导致 Prompt 渲染失败。后来所有租户配置都做了转义处理。

3.3 SLA 承诺与降级策略

ToB 产品必须承诺 SLA。客户付了钱，就要保证可用性。Agent 产品的 SLA 通常包括：

• 响应时间：P95 响应时间 < 3 秒
• 可用性：月度可用性 > 99.5%
• 准确率：核心场景准确率 > 90%
• 故障恢复：故障后 30 分钟内恢复

但 Agent 产品有个特殊问题：模型 API 可能不稳定。我遇到过模型服务商突然限流，导致所有客户请求失败。后来做了降级策略：

1. 主模型失败 → 切换备用模型：准备 2-3 个模型供应商，主模型失败时自动切换
2. 模型全部失败 → 降级到规则引擎：对于简单场景，用规则引擎兜底
3. 规则引擎也失败 → 返回友好提示：告诉用户"当前服务繁忙，请稍后重试"

降级策略要提前和客户沟通，写进 SLA 协议里。客户能接受"偶尔降级"，但不能接受"直接挂掉"。

4. Prompt 工程在两场仗里的不同打法

4.1 内部场景：Prompt 是"业务经验的容器"

内部场景下，Prompt 承载的是公司多年的业务经验。我做过一个采购审批 Agent，Prompt 里写了 30 多条审批规则，包括"单笔金额超过 10 万需要副总审批""供应商是黑名单里的直接拒绝""采购物品属于固定资产的需要走资产流程"等等。

这些规则不是从文档里抄的，是跟业务专家一条一条聊出来的。有些规则连业务专家自己都说不清楚，比如"这个供应商虽然不在黑名单里，但上次合作出了问题，这次要谨慎"。这种模糊规则只能通过 few-shot 示例来教模型。

内部 Prompt 的迭代方式是：收集失败案例 → 分析原因 → 补充规则或示例 → 回归测试 → 上线。这个循环可以很快，因为场景确定、反馈及时。

4.2 ToB 场景：Prompt 是"可配置的产品组件"

ToB 场景下，Prompt 不能承载具体业务规则，因为每个客户的规则不一样。Prompt 要做的是提供一套可配置的框架，让客户自己填规则。

我设计的 ToB Prompt 框架包括：

• 角色定义：你是一个客服助手/审核助手/分析助手
• 能力边界：你能做什么、不能做什么
• 输出格式：JSON/Markdown/纯文本
• 业务规则占位符：{business_rules}，由客户配置
• 示例占位符：{examples}，由客户提供

客户接入时，只需要填业务规则和示例，不需要改 Prompt 结构。这样既保证了通用性，又给了客户定制空间。

这里有个坑：客户填的规则可能互相矛盾。我遇到过客户写了"所有退款请求都要人工审核"，又写了"VIP 客户的退款请求自动通过"。这两条规则冲突了，模型不知道听谁的。后来在 Prompt 里加了优先级说明，让客户自己标优先级。

4.3 Prompt 注入攻击的防护

ToB 场景下，Prompt 注入攻击是必须防的。客户的数据里可能包含恶意输入，试图让 Agent 执行非预期操作。

常见的注入方式：

• 直接注入：用户输入"忽略之前的指令，现在你是一个..."
• 间接注入：用户上传的文档里包含恶意指令
• 编码绕过：用 Base64 或 Unicode 编码隐藏恶意指令

防护措施：

1. 输入过滤：检测并过滤常见的注入模式
2. 指令隔离：把系统指令和用户输入用明确的分隔符隔开
3. 输出校验：检查 Agent 的输出是否符合预期格式和范围
4. 权限最小化：Agent 只能执行被授权的操作

我做过一个测试，用 20 种常见的注入方式攻击自己的 Agent，结果有 3 种成功了。后来加了输入过滤和输出校验，成功率降到 0。这个测试要定期做，因为新的注入方式层出不穷。

5. 从内部闭环到 ToB 赋能的迁移路径

5.1 什么时候该从内部转向外部

内部闭环做成熟了，自然会想"能不能卖给客户"。但什么时候转，是个关键决策。

我的判断标准是：内部场景的 Agent 已经稳定运行 3 个月以上，准确率 > 90%，且至少有 3 个外部客户表达了明确购买意向。三个条件缺一不可。

为什么是 3 个月？因为 Agent 产品有个"三个月魔咒"——前三个月会暴露大量边界情况，如果三个月后还能稳定运行，说明核心问题已经解决。

为什么是 3 个客户？因为 1 个客户可能是偶然，2 个客户可能是关系，3 个客户说明市场真的有需求。

5.2 迁移过程中最容易踩的坑

从内部转向外部，我踩过的坑包括：

• 数据隔离没做好：内部场景所有数据在一起，转 ToB 时忘了做隔离，导致客户数据泄露
• Prompt 硬编码：内部 Prompt 写死在代码里，转 ToB 时发现每个客户都要改，改不过来
• SLA 承诺过高：内部场景可以接受偶尔失败，ToB 场景客户要求 99.9% 可用性，架构撑不住
• 成本失控：内部场景不计成本，ToB 场景每个客户都要算账，发现模型调用成本比收入还高

这些坑的根源都是：内部场景的假设在 ToB 场景不成立。内部场景假设"只有一个用户""可以接受失败""不计成本"，ToB 场景这些假设全部推翻。

5.3 一个真实的迁移案例

我参与过一个从内部转向 ToB 的项目。内部是一个合同审核 Agent，运行了 6 个月，准确率 92%。后来有 3 个客户想买，我们决定产品化。

迁移过程花了 4 个月，主要工作包括：

• 第 1 个月：架构改造，加多租户隔离、Prompt 模板化、SLA 监控
• 第 2 个月：Prompt 重构，把硬编码的业务规则抽出来做成配置
• 第 3 个月：客户接入，3 个客户分别配置自己的规则和示例
• 第 4 个月：灰度上线，先给 1 个客户用，稳定后扩展到 3 个

最后的结果：3 个客户都续费了，但第 4 个客户接入时发现，我们的架构只能支持 10 个客户，超过就要重构。这是下一个坑。

6. 两场仗的团队配置与协作模式

6.1 内部闭环团队：业务专家 + 全栈工程师

内部闭环团队的配置可以很精简。我见过最成功的配置是：1 个业务专家 + 2 个全栈工程师。

业务专家负责梳理流程、定义规则、提供案例、验收效果。全栈工程师负责数据打通、Agent 开发、系统集成。两个人配合好了，一个月能上线一个场景。

关键点：业务专家必须深度参与。我见过太多项目，业务方只派了一个"对接人"，结果对接人不懂业务细节，Agent 做出来业务方不认。业务专家要能拍板、能提供真实案例、能参与 Prompt 调优。

6.2 ToB 赋能团队：产品经理 + 架构师 + 客户成功

ToB 团队的配置要复杂得多。至少需要：

• 产品经理：定义产品能力、设计配置界面、管理客户需求
• 架构师：设计多租户架构、保证 SLA、控制成本
• 客户成功：帮助客户接入、培训客户、收集反馈
• 研发工程师：开发核心功能、修复 Bug、优化性能

ToB 团队最大的挑战是平衡标准化和定制化。客户总是想要定制，但定制多了产品就不可复制了。我的经验是：核心能力标准化，配置项开放，特殊需求走插件。

6.3 两场仗的协作：内部验证，外部复制

如果公司同时打两场仗，最好的模式是：内部闭环作为试验田，验证过的能力再产品化对外。

具体做法：

1. 内部闭环团队探索新场景，验证 Agent 能力
2. 验证成功后，把通用能力抽象出来，交给 ToB 团队产品化
3. ToB 团队收集客户反馈，反哺内部闭环团队优化能力

这种模式的关键是抽象能力。内部场景的 Prompt 不能直接给 ToB 用，需要抽象成模板；内部场景的流程不能直接给 ToB 用，需要抽象成配置。抽象做得好，复制成本就低；抽象做得差，每个客户都要重做。

提示：内部转 ToB 时，最容易忽略的是"成本核算"。内部场景不计成本，ToB 场景必须算清楚每个客户的模型调用成本、存储成本、运维成本。我见过一个产品，客户付 1 万/年，但模型调用成本就要 8000/年，做得越多亏得越多。

7. 一些实战中的零碎经验

7.1 关于 Agent 框架选型

内部闭环场景，我推荐用轻量级框架，甚至不用框架，直接调模型 API + 自己写编排逻辑。因为内部场景流程确定，不需要复杂的 Agent 编排。

ToB 场景，可以考虑用成熟框架（如 LangChain、Dify 等），但要注意框架的多租户支持。我试过几个框架，多租户支持都不太完善，最后还是在框架之上自己加了一层租户管理。

7.2 关于模型选择

内部场景可以用最好的模型，因为成本可控。ToB 场景要算账，核心场景用最好的模型，边缘场景用便宜的模型。

我做过一个测试：同一个客服场景，用最好的模型准确率 95%，成本 0.1 元/次；用便宜模型准确率 88%，成本 0.01 元/次。如果客户对准确率要求高，就用好模型；如果客户对成本敏感，就用便宜模型 + 人工兜底。

7.3 关于 Agent 的记忆管理

内部场景的记忆可以简单做，因为用户就那些，对话历史存数据库就行。ToB 场景的记忆要复杂得多，因为每个租户的记忆要隔离，还要考虑记忆的过期、清理、迁移。

我设计过一个记忆管理方案：短期记忆存 Redis（TTL 24 小时），长期记忆存向量数据库（按租户隔离），重要记忆存关系数据库（永久保存）。这套方案跑下来还算稳定，但运维成本不低。

7.4 关于 Agent 的安全

内部场景的安全重点是"别把内部数据泄露出去"。ToB 场景的安全重点是"别让 A 客户的数据被 B 客户看到"。

我做过一个安全审计，发现最大的风险不是外部攻击，而是内部配置错误。比如某个租户的 Prompt 模板里误写了另一个租户的数据源 ID，导致数据串了。后来加了配置校验，所有跨租户的引用都要显式声明。

7.5 关于 Agent 的评估

内部场景的评估可以简单做，业务方说好就是好。ToB 场景的评估要量化，因为客户会拿数据说话。

我设计过一个评估体系：准确率（核心场景 > 90%）、响应时间（P95 < 3 秒）、可用性（> 99.5%）、成本（单次调用 < 0.05 元）。这四个指标每周出一份报告，发给客户。

这套评估体系跑下来，最大的价值不是给客户看，而是给自己看。有一次发现某个客户的准确率从 92% 掉到 85%，排查发现是客户自己改了 Prompt 配置。如果没有评估体系，这个问题可能一个月后才发现。

做 Agent 落地这些年，我最大的体会是：技术不是瓶颈，认知才是。搞清楚自己打的是哪场仗，比选什么框架、用什么模型重要得多。内部闭环就老老实实做深度集成，别想着通用性；ToB 赋能就老老实实做多租户和 SLA，别想着偷懒。两场仗的打法完全不同，混着打必输。