公众号的下一篇文章，打算好好写一写 AI 时代的组织变革。

这个话题其实有点大。在里面有一个我觉得比较重要的分论点，现在某种程度上也是一种共识：人（这里特指 leader）是没有办法领导一场自己没有参与的革命的。

所以，那些还在用豆包问答、看着各种浮夸的 open claw公众号搞 AI 大跃进的领导，其实是挺危险的。

与诸君共勉，写于出差途中。

我之前在公众号的文章中辨析过上一个时代的产业协同模式和 AI 应用建设产业协同模式的区别，但是并没有触及到本质。

接下来，我本来想写一下企业如何进行业务的语义建模，也就是实施 Palantir 本体论的方法。在这个过程中我发现
似乎逐渐看到了这个命题的答案：在传统的软件工程中，产品经理写 PRD（给人类看），工程师写 Code（给机器看），两者之间存在巨大的损耗与认知偏差。

但在带 Ontology 的 Agent 建设中，你们必须建立一个“机器与人类同读同构”的中间态组件。这个组件，就是你们双方日常协同的主战场：

1. 机器可读的 SOP 与指令文档（例如 `AGENTS.md`）：
• 产品负责： 用纯自然语言但在结构上极度严谨（极简表达）的方式，维护 Agent 的行为准则、角色定义和标准业务流程（SOP）。
• 研发负责： 将这个文档直接作为 Context Engineering 的核心输入（System Prompt 的基座或 RAG 的第一优先级），确保文档一更新，Agent 的“大脑”直接同步 。

2. API 契约作为知识图谱边界：
• 产品决定某个 Action（如“撤单”）的输入输出参数（需要提供审批流 ID、撤单原因）。如果产品没在 Ontology 里定义这个属性，研发就绝不能在给 Agent 的 Tool Schema 里暴露这个字段。
• 约束：工具的 Schema 就是 Ontology 的边界，一点都不能多，多就是熵增。

今天听到有人讲，从产品上看，C 端的 AI 发展得比 B 端的 AI 产品更成熟。给出的理由是：C 端场景更需要创意，更需要扩散，而B 端的场景要更收敛，追求稳定性和精确度。

先说结论，我是不认可这个思维逻辑的。因为 C 端难道就没有很多需要稳定性和准确度的场景吗？比如说，ChatGPT 和 Claude 的 Agent 现在都在切入到 MS Office的场景里面，无论是数据分析还是文档写作，其实都需要一定程度的准确度。比如最早的一批 C 端的 AI 场景 Deep Research，长时间以来最大的痛点就是准确度和稳定性的问题。

反过来我们看 B 端，B 端不需要创意和发散性吗？也不是。最早的一批 B 端的 AI 应用场景，大语言模型 AI 应用场景里面就有很多营销物料的生成，包括各种模态的物料，这都是非常典型的 B 端场景。

所以我认为不讨论结论正确与否，从思维路径和认知上来讲，这样的思维链就是非常老旧的，属于上一个时代的思考方式。C 端比 B 端发展得要成熟, 我认为本质原因是因为当前 C 端的用户需求门槛要低一些，更容易被满足。

而 B 端为什么难？难在哪？主要原因有几点：
1. B 端场景的上下文要求非常高。因为 B 端是组织形态，上下文不是单一个体独享的，而是组织共享的。这样以组织视角出发的上下文是非常难以达到一个比较高质量的。现在基本上已经是一个共识，就是上下文的质量直接决定了任务的执行质量。而且更不要提 B 端企业很多的上下文并不掌握在非结构化的文件，而是掌握在各种烟囱式结构化的系统里面，就更难去做上下文的聚合和治理。
2. B 端的场景真正能起到价值的，往往都是比较长的业务链路的执行。而这种长业务链路的执行本身在当前阶段就是一个比较前沿，还没有被完美解决的一个课题。
3. 对于 B 端而言，我们所谓的数据资产并没有被充分地语义化。就是即使在上一个时代企业做好了上一个时代标准下的高质量的数据治理，也不代表 AI 工具可以非常顺畅高效地去做接入。这个话题其实我非常感兴趣，它也是一个很复杂的 topic，后面我会独立地再去写文章去介绍一下本体论的思想。
4. 安全合规和权限管控这一部分。对于 C 端来说，因为单一账号、单一工具是服务单一个体的。但是在 B 端场景，涉及到企业间、部门间、岗位间、人员间的数据和能力的隔离。更不要提对一些复杂业务，还涉及到各种业务语义的隔离维度，那就会造成极其复杂的数据和能力的管理。那管理背后又会带来审计，又会带来运行时的监控，又会带来运行前的预检。这些能力在 B 端，坦诚讲，以我有限的视野，我并没有看到非常成熟的解决方案，多数还是在探索阶段，而且并没有成体系化。

以上才是我认为为什么当前 C 端场景比 B 端场景产品更成熟的一个底层原因。那是不是可以同样地推理出 AI 在C 端的应用价值比 B 端应用价值高呢？这里是一个没有明确答案的公开话题。目前我对这个判断是存疑的。可能在互联网时代和移动互联网时代，我们看到C端产生了更大的价值。但在 AI 时代，我认为这是一个 B端的黄金时代。

我对企业关于这次 OpenClaw技术潮流的建议是：应该旗帜鲜明地反对员工在工作场景去使用以任何形式部署的私人 OpenClaw。

因为这个解决方案当前并不是很成熟，尤其是在安全合规方向上。对于一个个人向的实验项目，如果允许员工在工作场景中使用，无异于在物理世界允许员工带陌生人到工位上参与日常工作。试问哪家企业在物理世界能有如此高的包容度？

当然，我并不认为这是一种技术保守主义。因为不仅 OpenClaw 不是个筐，Agent 也不是个筐，不是万灵药，什么都要往里装。

关于企业内部的 AI 能力建设和产品能力建设，其实有五种主流的产品形态，后续我会单独写文章去介绍。

务实，似乎变成了当下这个时代非常宝贵的一种品质。

当前在很多企业进行内部 AI 建设的时候，有一个有趣现象：对一些基本的重要概念的认知，在跨团队甚至上下级之间都无法对齐。

在我看到的这些现象背后，我做一个大胆的推测：其实国内很多项目组，连什么是 session（终端用户的对话 session 和 MCP server-client 之间的 session）的关系，都是讲不清的。

这是一个忙乱慌张发展的阶段。在这个阶段，为什么像 O openclaw这种泡沫现象会发生，也不足为奇。

MCP 不是替代 API，而是在 Agent 和 API 之间增加了一层专为 LLM 推理方式设计的标准化编排层。用架构视角做个类比，MCP 之于 Agent 生态，就像 ESB/API Gateway 之于微服务。

第一个主要的不同：通过 MCP 可以进行状态管理（Stateful Sessions）

传统 API 调用是无状态的，每次请求都是孤立的。MCP 维护跨请求的会话状态，让 Agent 能执行真正的多步骤复合任务，而不是每次都重新建立上下文。

Agent 直接写代码：用户问"帮我查一下我最近买的跑鞋"，Agent 调 API 拿到订单数据，然后用户继续问："这双鞋还在保修期内吗？"——此时 Agent 必须重新传入 user_id + 订单号，把上一步的结果手动拼进新请求，否则 API 不知道"这双鞋"是哪一双。

MCP 的做法：MCP Server 在会话建立时生成一个 session_id，第一次查询"张三最近的订单"后，Server 把结果存入 session state。用户问"这双鞋保修状态"时，Server 已知道"这双鞋"= order_id: 88023，直接用缓存数据查保修，无需 Agent 重复传递上下文。

第二个主要不同：MCP 协议可以进行能力抽象（High-Level Capabilities）

直接调 API 会把 createUser、updateUserAddress、resetPassword 等几十个低级接口全部暴露给 LLM，造成"工具过载"，严重影响推理质量。MCP Server 可以把这些低级接口封装成一个高级能力 manageUserProfile，让 Agent 专注于目标而非实现细节。

Agent 直接写代码：为了让 Agent 能"帮用户完成退货"，需要暴露 5 个底层接口（查订单、创建退货、更新库存、触发退款、发邮件）。LLM 需要自己推断调用顺序、处理错误码，出错概率极高。

MCP 的做法：将上述 5 步封装成一个高级能力 process_return(order_id, reason)，内部按固定业务流程执行，每一步失败都有统一回滚逻辑。Agent 只需调用这一个工具，完全不需要知道底层有几个接口。

最近一个想法越来越清晰：B端产品经理最核心的能力迁移，不是学会用AI工具，而是从"定义功能"变成"定义智能"。

过去我们写PRD，本质上是在回答"这个按钮点了该跳到哪"。对错分明，非黑即白。但你怎么评价一个AI Agent生成的销售分析报告？它70%很有洞见，30%流于表面——这算"对"还是"错"？

这就是范式变了。产品经理对产品的定义权，从PRD转移到了Eval Set（评测集）。你设计什么样的评测维度，就定义了什么样的"智能"。

说白了，你不再是功能的定义者，你是智能的裁判。

你们团队现在是怎么评估AI产出质量的？有没有什么野路子特别好用？🤔

#AI产品经理 #数字化转型 #B端产品

来到即刻的第一天。