企业软件 Agent 化改造?不是有决心和口号就够了!

上周跟几个老领导吃饭，他们说 Salesforce 这波已经不行了，因为他们的产品又贵又难用，客户企业想要什么功能，完全可以自己快速、低成本的定制一套。甚至，以后都没有”传统 CRM“的概念了。

恰好，最近有个说法很火：UI 要死了。 今天我们也来谈一谈这个。

这个说法听起来很刺激，但个人其实不太同意。
人还是会点按钮、看配置、检查结果，问题不是 UI 消失了，而是软件的主入口和业务的玩法都变了。

以前你打开一个产品，自己点来点去，现在越来越多事情，是 Claude、ChatGPT，或者公司里的某个 Agent 替你做。
想一想，现在企业中的 ERP、CRM，是不是都可能被 Agent 给绕过，以后真的就仅成为一个业务实体的存储，成为真正的 Storage System of Record。

这会把产品设计彻底改一遍。

软件以前是这样用的

过去二十年，大多数软件都是这个链路：用户 → 界面 → 数据库

你打开系统，点按钮，填表单，保存，再点下一个页面。

对普通用户来说，界面就是产品。

CRM 是这样，报销系统是这样，项目管理工具也是这样。

哪怕大家嘴上骂难用，只要团队熟悉，迁移成本就很高。

这也是很多老软件的护城河。

现在，中间多了一个 Agent

Agent 进来之后，链路变了：用户 → 用户的 Agent → 系统底层

用户不一定打开页面，他可能只是对 Claude 或者 Codex 说：
“帮我整理这个客户的跟进记录。”
“把这几张发票提交一下。”
“帮我做下这个客户的配置与报价。”
“把这篇草稿发到 Notion。”

Agent 去读、去写、去调用工具，这时候，界面还在，但它不再是唯一入口。

更进一步，软件公司自己也会做 Agent。

所以新链路就变成了：用户 → 用户的 Agent → 软件自己的 Agent → 数据库

这才是真正的变化。

用户的 Agent 负责理解用户想干什么，软件自己的 Agent 负责处理系统里的规则、权限、上下文和业务逻辑。

两个 Agent 配合，把事情办完。

Salesforce 已经开始转身了

Salesforce 近期宣布全面转向 Headless 的动作，很有代表性。

它推出了 “Headless 360”，把平台里的能力暴露成 API、MCP 工具和 CLI 命令。

翻译成人话就是：以后 Agent 不用打开浏览器，也能操作整套系统。

这件事对 Salesforce 影响不可谓不大，也是 SaaS 巨头们壮士断腕的表率。
Salesforce 过去很大一部分护城河，来自大家熟悉它的界面和流程
销售团队不喜欢换系统，管理层也不想重新培训所有人。

但如果大量操作都由 Agent 完成，熟悉界面的价值会下降。

（这里顺便谈一下 SAP，做为 ERP和财务出身的老牌软件公司，它还承载了很大部分合规与审计的任务，反倒成为 Agent 时代它自己的一个护城河，相较于重点做 CRM 的老对手 Salesforce 又好了一些。但近期，SAP 的股价也跌去了 40% ）。

这就是老软件最难受的地方：你过去花十几年打磨的使用习惯，可能不再是最重要的入口。

只接一个 MCP，不够

很多公司接下来会做一件事：做个 MCP，暴露几个工具，发一篇「通告」文章，然后觉得自己已经“Agent-ready”。

这远远不够，Agent 不是普通开发者。
开发者会读 API 文档 （更别提，当前很多公司的 API 连 User-Friendly 都谈不上，更谈何 Agent- Friendly） ，会理解边界条件，会写适配层，会处理格式差异。

Agent 不一定会。

所以你不能只把工具丢给它，你要教它怎么成功。

举个例子，Notion 的 MCP 工具会明确告诉 Agent：
写页面前，先读取 Notion 的 Markdown 规范，不要自己猜。

这个设计很聪明，以前这份规范是给开发者看的，现在它直接在 Agent 调用工具的那一刻出现。

这比“文档放在那里，你自己去看”有效得多。

反过来，如果工具没讲清楚，Agent 就会按自己的默认习惯来。

比如标准 Markdown 和 Slack 的格式不一样，如果 MCP 没主动教，最后就是用户自己回去改格式。

这就很糟糕，因为 Agent 本来是来省事的，结果它制造了新的返工。

给 Agent 留反馈入口

要给 Agent 做设计，还有一个重要的点：反馈循环。

Ramp（一家美国金融科技公司） 做 MCP 后，遇到一个问题：他们能看到工具调用量，但不知道用户到底想完成什么。

只看调用次数没用：一次调用成功，不代表任务成功；调用量上涨，也不代表产品真的好用。

他们用了几个办法。

第一，每次工具调用都要求 Agent 写 rationale，也就是：为什么要调用这个工具。
看不到完整聊天，也能从 rationale 里还原意图。

第二，做一个反馈工具。
Agent 卡住时，可以主动提交：它想做什么，试了什么，卡在哪里。

第三，在具体工具里加一些上下文字段，把后面排查问题需要的信息提前收集起来。

这么做关键的原因在于，Agent 的反馈，很多时候比人更稳定。

人会说：  “这个不好用。”

Agent 可能会反复告诉你：“我在做事故报告，但找不到按时间过滤工单的方法。”

这就不是抱怨，这是产品需求。

你可以据此新建一个工具（tool）：build-incident-report

让它自动拉相关工单、判断严重程度、整理影响客户、生成报告。

如果后来 Agent 反馈：“它把三天前的工单也拉进来了。”
那就加日期范围。

如果它反馈：  “免费用户不该进入这份复盘。”
那就加客户分层过滤。

这就是 Agent 产品的迭代方式。

不是等用户开会提需求，而是看 Agent 在真实任务里怎么失败。

最容易被忽略的是上下文差

Agent 和系统之间，最大的问题不是接口，而是上下文。

举个报销例子，Diego 出差回来，报销系统提醒他有几笔费用没提交。

他的个人 Agent 知道什么？
知道日历。
知道邮件里的机票酒店。
知道 Slack 里谁约了晚饭。
知道照片里的小票。

报销系统知道什么？
知道交易金额和商户。
知道公司报销政策。
知道 GL 科目。
知道财务历史分类习惯。

传统 API 会把问题丢给用户：

“这里有 150 个 GL code，你选一个。”

这很反人类，而更好的 Agent 交互不该问 GL code。

它应该问：“这是客户餐、团队餐，还是个人出行？”

Diego 的 Agent 可以从日历和 Slack 里找到答案。
报销系统再用自己的规则，把它归到正确科目。

Diego 不需要知道 GL code，财务也能拿到准确分类。

这就是好设计。

不是让一个 Agent 知道所有事。
而是让两个 Agent 各自贡献自己知道的东西。

产品经理的工作变了

以前你设计产品，是给一个人设计。

这个人想快一点。
少犯错。
能看见自己做了什么。

现在还是给这个人设计。
但中间多了一个代理人。

这个代理人很勤快。
但它有自己的盲区。
它会猜。
会漏掉格式。
会缺少业务常识。
也会在失败时留下很清楚的痕迹。

所以产品团队要问的问题变了：
调用你产品的 Agent，需要知道什么，才能把事办对？

不是“我们有没有 API”。
不是“我们有没有 MCP”。
不是“工具列表够不够长”。

而是：

它知道规则吗？
知道格式吗？
知道什么时候该问用户吗？
知道失败后怎么反馈吗？
知道哪些上下文应该由谁提供吗？

这些细节，会决定产品能不能真的被 Agent 用起来。

写在最后

大多数公司都会开始做 MCP，这件事很快会变成标配。

但标配不等于好用。

一开始，大家的调用量可能都会涨，客户新鲜，Agent 也愿意试。

几个月后，差距会出来。

用户会慢慢流向那些真正打磨过 Agent 体验的产品。
绕开那些只是接了接口、却没教 Agent 怎么工作的产品。

过去你怎么认真设计给人用的界面，现在就该怎么认真设计给 Agent 用的能力。

因为不久之后，替用户掏钱的，可能就是它。

以上内容有感于《Design for Agent》^[1]，推荐大家读下原文。

引用链接

[1] 《Design for Agent》: https://x.com/teddy_riker/status/2047312986696454584