SMT工厂数字孪生落地：2026实战选型手册
2026/4/25 7:35:57
过去三年，我亲眼看着 Ramp 的 MCP 周活跃用户在短短三个月内暴增 10 倍，客户不再打开浏览器，而是直接让 Claude、ChatGPT 等 Agent 代为操作整个财务系统。几乎同一时间，Salesforce 在 TDX 大会上推出 Headless 360，把 27 年积累的全部能力一次性暴露为 API、MCP tool 和 CLI 命令，让 Agent 无需任何图形界面就能完整驱动 CRM。这不是孤立事件，而是行业共识被硬生生撕开一道裂口：我们曾经坚信的“UI 才是产品护城河”正在快速失效。
我起初以为 UI 依然是企业软件的底线——销售团队需要熟悉的界面、配置可视化、操作留痕，结果 Ramp 的真实数据和 Salesforce 的战略动作把我彻底打醒。80/20 规则已经彻底翻转：80% 的交互将由 Agent 完成，剩下 20% 才是人类点鼠标的场景。产品团队如果还把主要精力花在像素级打磨 UI，而忽略 Agent 层面的确定性交付，就等于在为下一代用户筑墙把自己挡在外面。
传统交互范式的底层断裂
过去二十年的交互模型极其简单：
User → Interface → Database
界面就是产品，用户通过点击完成一切。现在 Agent 介入后，模型变成了：
User → User’s Agent → Software’s Agent → Database
更进一步，当软件方也构建自己的 Agent 能力时，就演变为：
User → User’s Agent → Software’s Agent → Database
两个 Agent 直接对话，完成业务闭环。这不是简单的“API 升级”，而是交互主体从人类切换到 Agent，设计哲学必须随之重构。我把这称为“Agent-to-Agent 范式”——它要求我们把过去给开发者的 API 文档，变成 Agent 运行时能直接消费的确定性规范。
（建议在实际产品文档中直接嵌入这个时序图，帮助团队快速对齐认知。）
教 Agent 如何成功：把规范推到运行时而非文档里
Notion 的 MCP 工具做得特别狠。它们的notion-create-pages工具描述第一行就写死：“For the complete Markdown specification, always first fetch the MCP resource at notion://docs/enhanced-markdown-spec. Do NOT guess or hallucinate Markdown syntax.” Agent 一执行就先拉最新规范，再写内容，结果表格、列表、斜体从不出错。
相比之下，Slack 的 MCP 体验则是反面教材：Agent 按通用 Markdown 输出，经常格式崩坏，用户还得手动修复。这背后的逻辑其实很简单——就像给新手厨师准备食材时，你是把菜谱直接塞进他手里，还是只丢一句“参考网上教程”？前者让执行确定性爆炸式提升，后者把所有不确定性甩给了 Agent 运行时。
构建反馈闭环：让 Agent 成为产品经理的延伸
Ramp 早期 MCP 最大的痛点是只能看到工具调用量，看不到调用背后的真实意图。后来他们强制要求每个 tool call 必须带rationale参数，Agent 必须解释“为什么调用这个工具、想达成什么目标”。同时增加了一个专用的 feedback tool，Agent 卡住时可以主动上报“尝试了什么、哪里失败、期望行为”。
这些日志里反复出现的模式，直接变成了新功能：比如大量 rationale 提到“building an incident report”，团队就快速迭代出一个build-incident-report工具，自动拉票、打分、生成强规范总结。Agent 反馈“拉了三天前的无关票”→ 立即加上日期范围参数；反馈“包含了免费用户”→ 加上 segment 过滤器。产品迭代从“人类 PM 猜需求”变成了“Agent 直接告诉你该怎么修”。
弥合上下文鸿沟：两个 Agent 各取所长
以 Diego 出差报销为例：
- 用户 Agent（Diego 的首席 AI 助手）掌握：日历、邮件附件、Slack 对话、照片收据
- 软件 Agent（Ramp 侧）掌握：原始交易数据、公司政策、GL 科目历史编码模式
传统 API 会把问题甩回用户：“这里有笔交易，请你选 GL code”。而 Agent-to-Agent 交互则是：软件 Agent 只问“这是客户餐、团队餐还是个人？”用户 Agent 从日历/Slack 里拉上下文，软件 Agent 自动应用规则完成编码。双方都不需要对方掌握自己的全部知识，却共同交付了更准的结果。
这就像两个专业医生会诊：一个掌握患者病史，另一个掌握最新诊疗指南。谁都不需要变成对方，只要明确“上下文鸿沟”在哪里，并主动补齐就够了。
为了让团队快速对齐，我整理了一个决策矩阵，帮大家一眼看清新旧范式的核心权衡：
| 维度 | 传统 UI 中心设计 | Agent-to-Agent MCP 设计 | 核心影响 |
|---|---|---|---|
| 主要交互主体 | 人类用户 | 用户 Agent + 软件 Agent | 设计焦点从像素转向确定性规范 |
| 上下文处理 | 用户手动输入/选择 | 双方主动互补（rationale + feedback） | 错误率大幅降低 |
| 迭代速度 | 依赖人类反馈 | Agent 直接产出结构化日志与需求 | 从周级迭代到天级 |
| 护城河来源 | 熟悉的界面与操作路径 | 教 Agent 成功的规范 + 反馈闭环 | 长期黏性来自“Agent 体验” |
| 人类角色 | 主要执行者 | 战略监督者（20% 场景） | 人类解放到高价值判断 |
为什么这套路径才是当前最务实的 Agent 原生架构
UI 没有死，人类依然需要可视化验证和偶尔的手动操作。但 80% 的日常工作流已经转移到 Agent 身上。Salesforce 敢于把 27 年 UI 积累的“熟悉感”作为代价，来换取 Agent 原生能力，正是因为他们看清了趋势：未来写支票的不是销售，而是“Agent 驱动的决策链”。Ramp 的 10x 增长也验证了这一点——真正让 Agent 好用、可靠、能自我迭代的产品，才会在下一波浪潮里被优先选择。
当然，这套范式也有边界：Agent 间的信任协议、数据隐私边界、极端异常兜底机制都需要额外设计。但相比继续把精力耗在“让 UI 再漂亮 10%”上，把 MCP 打造成 Agent 能真正依赖的确定性层，回报要高出一个数量级。
在生产环境落地 MCP 前你必须验证的三件事
- 每个核心 tool 都必须在描述里主动注入最新规范（spec），禁止让 Agent 猜测。
- 强制 rationale + feedback tool，形成闭环日志，让 Agent 直接驱动产品迭代。
- 明确定义“上下文鸿沟”，在工具参数设计阶段就写死双方各自的优势领域。
当你真正把产品从“给人类用”切换到“给 Agent 用”时，会突然发现：Agent 不再是外部调用方，而是和你并肩作战的“产品同事”。它会精准告诉你哪里需要改进，也会把你的业务规则执行得比任何人类团队都一致。
你目前的产品 MCP 里，是否已经为 Agent 准备好规范注入和反馈机制？在实际 Agent-to-Agent 交互中，你遇到过哪些最棘手的上下文鸿沟？欢迎在评论区分享你的实践，我们一起把企业软件的下一代交互层真正夯实。
我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。