本文核心观点：软件产品正在从"给人操作的界面"变成"给人和 Agent 共同调用的运行底座"。这不是 UI 死了，而是产品需要同时拥有两张脸——一张给人看，一张给 Agent 用。

核心要点：

- Agent 成为新的调用方，产品不能只有给人看的界面

- 工具可用 ≠ Agent 会用，语义层是最薄弱的一环

- 静态流程适合面向客户的 Agent，动态任务适合内部员工 Agent

- 确定性基础设施（Script、审计、回滚）是 Agent 进生产的前提

- 产品架构分五层：表面层、调用层、语义层、业务底座、治理层

有一个问题，产品经理和架构师都开始回避不了：

如果你的用户不是人，而是 Agent，你的产品准备好了吗？

Salesforce 最近发布了 Headless 360，官方说法是"不再需要浏览器"。把市场语言剥掉，它说的其实就一句话：企业平台上的所有能力，现在都可以以 API、MCP 工具或 CLI 命令的形式，被 Agent 直接调用。

这个动作很现实，也很有代表性。如果未来用户越来越少打开 CRM 页面，而是让 Claude、企业内部 Agent 或 Slack 工作流替自己完成大部分操作，企业软件继续只守页面入口，风险会越来越大。

软件的入口正在变，但底座不能丢。

第一张脸：给人；第二张脸：给 Agent

过去做软件，默认调用方是人。所以设计围着人转：

- 页面是不是清晰？

- 按钮是不是明确？

- 表单能不能少填？

- 错误提示能不能让人看懂？

这些当然还重要。但 Agent 成为调用方之后，契约会多出一组截然不同的问题：

- 工具名和描述，能不能让 Agent 选对？

- 参数 schema 是不是足够明确？

- 调用失败之后，错误能不能恢复？

- 工具返回值，是给人看的，还是给下一步推理用的？

- 权限、审计有没有从 UI 下沉到平台层？

一个很土的自检问题：如果把页面拿掉，只给 Agent 一组工具和文档，它能不能知道这件事该怎么做、做到哪里算完成、错了之后怎么退回来？

如果答不上来，这个产品就还没为 Agent 准备好。

工具可用，不等于 Agent 会用

这里有一个很经典的对照案例。

Notion 的 MCP 工具会主动告诉 Agent：要创建页面，先去拉一份 Notion 自己的 Markdown 规范，别用通用 Markdown 当默认。结果是：Claude 推送到 Notion 的内容，表格、列表、引用，基本每次格式都是对的。

Slack MCP 反过来。Agent 默认按通用 Markdown 写消息，Slack 自己的格式被忽略，发出去的消息样式怪，用户还要手动再改一遍。

两个 MCP 都"可用"，但体验差了一大截。原因只有一个：Notion 写清楚了规范，Slack 没有。

传统 API 文档写给开发者，开发者会读、会理解、会写转换层。Agent 时代，很多调用发生在运行时，系统得能在 Agent 需要的那一刻，把规范、schema、policy、示例直接递给它。

文档不只是售后和开发者体验的一部分，它会变成产品接口的一部分。写得含糊，Agent 就含糊地调；把边界讲清楚，Agent 才有机会稳定干活。

两类 Agent，两种控制强度

面向客户的 Agent，比如客服、咨询、售后，通常需要强确定性。它要遵守品牌规则、合规边界和业务流程，很多时候不能自由探索。更合适的结构是相对静态的流程图：确认身份→识别意图→收集信息→调用工具→返回结果，必要时转人工。

员工自己用的 Agent，比如 coding agent、销售研究、市场素材生成，可以放得更开。员工本身是专家，会检查输出、决定能不能发出去。这种场景里，Agent 可以动态展开任务路径，失败了换一条，发现新线索再继续搜。

两类场景对比：

面向客户的 Agent：静态流程图 / 约束合规、品牌、可审计 / 人负责兜底和审批

员工使用的 Agent：动态任务图 / 约束效率、工具覆盖、上下文质量 / 人负责审阅和决策

很多产品爱犯一个错：把"能自由推理"当成所有场景的优点。但在财务审批、客户服务、法务流程里，自由推理本身可能是风险。反过来，在代码生成、研究探索里，过强的静态流程又会把 Agent 绑死。

Agent 进生产，绕不开确定性基础设施

原型阶段 Agent 看着挺聪明：给它工具、给它上下文，能跑出 demo。但上线之后问题会变得很具体：

- 改一句提示词，会不会影响原来跑通的流程？

- 哪些步骤可以让模型自由推理，哪些步骤要按业务规则强制执行？

- 失败之后能不能回放？

- 新版本能不能和旧版本做 A/B？

- 最后是谁批准了这个动作？

有一个真实案例：早期 Agentforce 客户把 Agent 做进生产之后，反而不敢改了，因为系统太脆。动一点就不知道会不会还稳，所有测试都得重做。

这是一个很常见的困境："它终于能干活了" → "我不敢改它了"。

这就是为什么企业需要 Agent Script 这类中间层——把自然语言指令的灵活性，和程序化表达式处理业务规则的可靠性结合起来。模型在某些节点自由决定，业务规则在另一些节点强制执行。

这个思路和 Harness 工程是一脉相承的：模型越强，外面的系统越重要。 最后能不能交付，不只看模型会不会答，还得看主循环、工具、上下文、权限、状态、验证和回滚能不能一起工作。

Agent 友好的产品五层架构

把所有这些放一起，我会把"Agent 友好的产品"拆成五层：

第一层：表面层

用户不一定在你的产品页面里，他可能在 Slack、Teams、ChatGPT、Claude 或企业工作台里。产品要接受：入口会分散，但底座要在。

第二层：调用层

Agent 通过 API、CLI、MCP 或 Tool Registry 进入系统。先解决最实在的问题：接口稳不稳定、能不能被发现、鉴权和限流够不够。

第三层：语义层（最薄弱）

工具描述、schema、policy、错误契约、示例都在这里。它们决定 Agent 是少猜，还是一路猜。很多时候问题不在 Agent 能力，而在产品给它的语义太粗。

第四层：业务底座

这是产品多年攒下来的部分：数据、流程、业务逻辑、历史记录、组织权限和过程资产。企业软件在这里尤其重，因为它背后连着组织的真实运转方式。

第五层：治理层

认证、授权、审计、测试、评估、观测、回滚、计费。Agent 能做的事越多，这层越不能靠临时补丁。

五层里最容易被忽视的是第三层（语义层）和第五层（治理层）。很多团队会先做第二层：发 API、接 MCP、写插件。但没有语义层，Agent 还是会猜；没有治理层，企业也不敢让它真做事。

"加了 Agent 入口"和"Agent 友好的产品"，差距就在第三层和第五层。

一句话总结

为 Agent 设计产品，不是把页面换成 API，而是把产品能力整理成 Agent 能理解、能调用、能被约束、能被审计的动作。

软件正在长出第二张脸。你的产品，第二张脸准备好了吗？