上个月和一个做制造业的客户聊。他们花了三个月，把内部的工艺参数、良率数据、供应商评分全部结构化，喂给了一个通用模型的 RAG 系统。效果确实好——Agent 回答的工艺问题比他们自己工程师还准，内部试用两周，业务部门已经开始依赖了。
然后 CTO 问了我一个问题：「如果我的竞品也买了同一个模型的 API，我的这些知识会不会变成模型的一部分，间接服务于他？」
我沉默了几秒。不是技术上做不到隔离——模型厂商的合同里确实写着不训练、不留存。但我没法告诉他怎么 验证 这一点。这是一个 信任问题，不是技术问题。
这个问题让我意识到：关于「模型和 Agent 的边界」的讨论，我们一直只从技术视角切入。但实际上，决定这条边界的不是能力，而是 数据主权。
两个趋势在同时发生
趋势一：模型在「吞噬」Agent 的能力层
两年前，Agent 框架的核心差异化是「会调工具、会规划步骤」。现在主流模型原生就支持 function calling、multi-step reasoning、甚至 computer use。模型本身在变成一个内置 Agent 能力的推理引擎。
这意味着什么？我在 Agent = Model + Harness 中讨论过，Anthropic 工程团队自己说的：
Harnesses encode assumptions about what Claude can’t do on its own. Those assumptions go stale as models improve.
Harness 编码了「模型做不到什么」的假设，而这些假设随着模型迭代在迅速过时。通用 Agent 框架——那些以「编排」为核心卖点的产品——正在被模型本身抽走地基。
趋势二：通用模型的经济学是「广覆盖、低毛利」
模型厂商追求的是 token 吞吐量 × 用户规模。它的 ROI 公式是 用户数 × ARPU，不可能为某个企业的审批流程、某个行业的合规检查去深度优化。不是做不到，是 商业模型不允许。
通用模型越强，它就越是一层 商品化的推理基础设施——像云计算一样，按需调用、按量付费、无状态、无记忆。
这两个趋势加在一起，一个结论浮出来了： 模型和通用 Agent 的边界确实在模糊。但生产型 Agent 的边界不会消失，因为它的壁垒不在技术层，而在数据主权层。
数据隐私 ≠ 数据主权
这是本文最关键的区分。很多人把这两件事混为一谈，但它们完全不同：
| 数据隐私 | 数据主权 | |
|---|---|---|
| 核心问题 | 「我的数据不会被泄露」 | 「我的数据不会出现在竞争对手的推理路径上」 |
| 技术可行性 | 可以做到（不训练、不留存） | 结构性不可能（模型权重是共享的） |
| 信任门槛 | 技术信任 | 商业信任 |
| 企业的理性选择 | 接受厂商承诺 | 不接受，自己做 |
数据隐私 可以用合同和技术手段解决。模型厂商可以承诺不用你的数据训练、不留存你的 prompt。
数据主权 是一个更深层的问题。你的竞品和你用同一个模型 API。你把内部客户分析喂给模型做推理，竞品也喂了。哪怕厂商合同里写着「数据隔离」「不用于训练」——你怎么 验证？你拿不到模型权重，看不到微调日志，审计不到推理链路。更根本的是，即使厂商真没拿你的数据训练，你的 推理模式 （你问什么问题、怎么拆解任务、关注什么维度）已经暴露在了他们的服务器上。
这不是厂商做不做得到的问题——这是 理性企业不应该赌这一点 的问题。
生产型 Agent 的真正壁垒
如果企业要认真保护自己的竞争力，架构选择就很清晰了。
我在 模型和 Agent 的边界 中说过：「模型决定上限，Agent 决定你能不能稳定拿到这个上限。」这是从技术可靠性角度的判断。但现在我要补一个更锋利的维度：
生产型 Agent 的真正壁垒不在「会推理」（模型能做），而在「私有知识的组装与执行」。
通用模型再强，它拿不到你的：
- 内部审批链的历史决策模式
- 客户工单里反复出现但你从未公开发布过的 edge case
- 工程师在代码 review 里写的那些「只有我们懂」的 context
- 销售团队在 CRM 里沉淀的客户偏好和谈判策略
这些数据的价值，只有在 Agent 能规模化执行时才会被释放出来。 光有数据不行——放在数据库里它只是成本。光有 Agent 也不行——没有领域知识的 Agent 只是个通用聊天框。
是 「私有知识 × 规模执行」 这个乘法，定义了生产型 Agent 的不可替代性。
一张架构图说明白
模型变成了一个「无状态的推理引擎」—— 你只给它完成任务所需的最小上下文，而不是把整个知识库搬给它。私有知识永远留在 Agent 内部。
我在 基础设施比模型更重要 中讨论过类似判断，但当时的切入点是「可靠性」。现在看，这个判断的另一面是 控制权——谁控制上下文，谁就控制竞争力。
生产型 Agent 的性价比逻辑
除了数据主权，还有一个纯粹的经济学论证。
通用模型为了满足尽可能多的用户，必须是一个 全能型选手——什么都能做，什么都做到 80 分。但企业的生产型任务往往只需要 在 20% 的场景里做到 95 分。
| 维度 | 通用 Agent | 生产型 Agent |
|---|---|---|
| 任务范围 | 无限广 | 有限但精确 |
| 单任务成本 | 高（大模型 token 贵） | 低（可以选任务专用小模型） |
| 上下文效率 | 低（每次带通用 system prompt） | 高（只注入任务相关的私有知识） |
| 执行频率 | 按需 | 规模化、高频 |
| 错误容忍度 | 高（用户自己判断） | 低（生产环境，错误有业务后果） |
生产型 Agent 的 ROI 公式是：「用更小的模型、更精准的上下文、更高的频率，完成指定集合的任务」。在这个公式里，通用大模型反而是一种浪费——你在为一堆用不上的通用能力付费。
这和 AI to B 的最后一公里 的判断一致：企业真正需要的不是更强的模型，而是 更贴合自己业务的基础设施。
企业运行时的角色
这个逻辑推到极致，企业需要的不是一个 Agent 平台，而是一个 企业运行时（Enterprise Runtime）—— 一个托管企业上下文和学习闭环的环境。
什么意思？模型提供的是 世界知识 （World Knowledge），企业拥有的是 上下文 （Context）。组织、权限、IM、会议、文档、审批、流程、日程、知识库——这些不是静态数据，而是企业每天工作的实时上下文。
一个设计良好的企业运行时负责的是：
如果没有这个闭环，AI 永远停留在 Chat 而不是 Work。而这个闭环必须在企业自己的运行时上运行——因为它积累的是 企业的学习资产，不应该存在于模型厂商的服务器里。
这也是为什么模型可以被替换——今天是 Claude，明天可能是 Qwen，后天可能是 DeepSeek——但运行时不动。企业资产一直都在。
平台该怎么做：三个「友好」
如果这个判断成立，那面向企业的 Agent 平台应该怎么做？我认为要同时满足三个维度的「友好」：
对 Agent 友好
平台的第一用户不再是人类开发者，而是开发者的 Agent。
传统开放平台的逻辑是：设计好 API → 写好文档 → 人类读文档 → 写代码调用。新逻辑是：设计好 API → Agent 能理解参数语义 → 开发者通过 Coding Agent 完成开发。
具体来说：
- 参数命名自解释——
message_type而非type，枚举值用字符串而非数字 - Schema 机器可推理——Agent 不需要去查文档就能理解参数的约束和副作用
- 错误码结构化——Agent 能自动处理错误，而不只是给人类看的报错信息
我在 对 Agent 友好就是对开发者友好 中详细讨论过这个范式迁移——一个让 Agent 都能理解的平台，人类开发者用起来只会更顺畅。
对开发者友好
开发者需要的不是更多 API，而是一个 完整的开发范式——从 Agent 身份创建、权限配置、知识注入到部署上线，尽可能自动化。
理想状态是：开发者在一个统一的 CLI 环境中，一条命令创建 Agent、一条命令连接企业系统、一条命令部署到指定场景。整个过程不需要登录任何管理控制台，不需要手动配置权限矩阵。
开发过程本身就应该是一次 Agent 协作——开发者在 IDE 里和 Coding Agent 对话，Coding Agent 调用平台能力完成构建。这就是对话驱动的 Agent 开发（Conversation-Driven Agent Development）。
对企业友好
企业友好的核心是 让企业掌控自己的数据主权：
- Agent 有身份——像员工一样入职、授权、审计、离职。不是匿名 AI，是组织的一员
- 权限最小化——Agent 只拿到完成任务所需的最小权限，凭证不进入 Agent 运行环境
- 知识不外泄——企业的私有知识留在企业运行时内，只在必要时以最小上下文喂给模型
- 学习资产归属企业——Agent 积累的 Memory、Skill、Eval 数据，全部归企业所有，不随模型切换而消失
这三个「友好」不是三个独立的产品，而是同一个平台的三个切面。 对 Agent 友好决定了效率上限，对开发者友好决定了交付速度，对企业友好决定了信任底线。
反方观点：模型厂商会吞掉这一层吗？
最强的反驳可能是：模型厂商正在把「私有知识接入」做成产品。OpenAI 有 GPTs + file upload + RAG，Anthropic 在做 Projects，Google 有 Gemini + Workspace 集成。如果模型厂商把「接入你的私有数据」做成一行配置的事，生产型 Agent 的「私有知识」壁垒还剩多少？
我认为这里有一个关键区分——模型厂商做的是「被动检索」（你问它答），而生产型 Agent 做的是「主动执行」（它替你做完整个工作流）。 一个是搜索引擎加了 RAG，一个是替你跑完审批、更新表格、发送通知、追踪反馈。这两件事的难度差了一个数量级。
更重要的是，模型厂商做的「私有知识接入」仍然意味着 你的数据存在于他们的服务器上。对数据主权敏感的企业——也就是那些最有竞争力的企业——不会接受这一点。
模型会越来越强，但 模型越强，生产型 Agent 反而越值钱——因为当推理变成白菜价，差异化的来源就只剩下「你喂给它什么」。
所以边界在哪？
回到开头那个客户的问题。
模型和通用 Agent 的边界确实在模糊。模型在吞噬编排层，通用 Agent 框架的护城河在被抽走。这是技术层面的趋势，不可逆。
但生产型 Agent 和通用模型之间的边界不会消失，因为这条线不是技术画的，是 数据主权 画的。
- 模型是 世界知识 的提供者——通用的、共享的、可替代的
- 生产型 Agent 是 企业上下文 的守护者——私有的、独占的、不可替代的
模型可以换。运行时不能换。企业资产不能搬。
这不是一个技术架构的选择，这是一个 商业博弈的选择。而在这个博弈中，企业会理性地选择看不见的那条线——一条由数据主权划定的、把自己的竞争力锁在自己手里的线。
你的企业私有知识，值得一个只为你工作的 Agent。
你在企业 Agent 落地中遇到过数据主权方面的顾虑吗？欢迎留言讨论。