软件产品如何为 Agent 重新设计架构

大家好，我是苍一，一个干了13年的后端开发，正在探索AI编程，从产品到开发的全生命周期最佳实践，如果您感兴趣，欢迎关注👇，看我如何自我革命。

软件的调用方正在改变

之前讨论过”像 Agent 一样看世界”这个思路。落到工程实践上，核心观点很朴素：设计工具时不能只考虑人类的使用习惯，要关注模型实际怎么读取信息、选择工具、处理错误和恢复状态。

Salesforce 最近发布了 Headless 360，第一眼看像是一批新的 MCP、API 和 CLI。但仔细看下来，思路比预想的更远。

以前的问题是：怎么给 coding agent 设计好用的工具。

现在的问题变成了：如果 Agent 真正成为产品的新调用方，产品该怎么重新设计自己？

1️⃣ Headless 360 不只是”去掉界面”

官方拆成三块。第一，60 多个 MCP 工具加上 30 多个预配置 coding skills，让外部 coding agent 直接连进企业组织。第二，新的 Agentforce Experience Layer 把”做什么”和”长什么样”分离，一次定义就能渲染到 Slack、Teams、ChatGPT、Claude 等多个界面。第三，Agent Script 通用可用并开源，配合 Testing Center 和 A/B Testing API，覆盖 Agent 全生命周期。

重点不是放弃 UI，而是把 UI 背后的平台能力翻出来，让 Agent 也能用。

2️⃣ 给 Agent 写一张能看懂的说明书

过去做软件，默认调用方是人。Agent 成为调用方后，契约要多出一组不同的问题：工具名和描述能不能让 Agent 选对工具？参数 schema 是否足够明确？调用失败后错误能否恢复？权限、审计、计费有没有从 UI 下沉到平台？

Notion 和 Slack 是一个很好的对照组。Notion 的 MCP 工具会主动告诉 Agent 创建页面之前先拉一份自己的 Markdown 规范。用 Claude 写东西推到 Notion，格式基本不会出错。Slack MCP 反过来，Agent 默认按通用 Markdown 写消息，发出去的样式经常出问题。

工具可用不等于 Agent 会用。

Agent 进生产绕不开确定性

最值得关注的是 Agent Script。它解决的是一个特别现实的问题：企业不能只靠提示词把 Agent 放进生产。

模型本身是概率系统，企业流程要求可解释、可回放、可验证。Agent Script 的价值在于承认一件事：Agent 的自由推理和企业的确定性流程之间，需要一个中间层。

3️⃣ 客户 Agent 和员工 Agent 需要不同控制强度

面向客户的 Agent 通常需要更强的确定性，遵守品牌规则、合规边界和政策限制。员工自己用的 Agent 可以放得更开，员工本身是专家，会检查输出。

这两类模式应该跑在同一个底座上，数据、权限、工具、观测和治理层尽量复用。

Agent 友好产品的五层架构

第一层是表面层。用户不一定在你的产品页面里，入口会分散。第二层是调用层。Agent 通过 API、CLI、MCP 进入系统。第三层是语义层。工具描述、schema、policy、错误契约，决定 Agent 是少猜还是一路猜。第四层是业务底座。数据、流程、业务逻辑、历史记录。第五层是治理层。认证、授权、审计、测试、观测、回滚。

很多团队会先做第二层发 API，但缺少语义层 Agent 还是会猜，缺少治理层企业也不敢让它真做事。

具体行动建议

把高频能力拆成原子动作。Agent 调用时不能只丢一个粗接口，得说清楚这个动作能做什么、前置条件是什么、失败能不能重试。

把权限和审计从 UI 下沉到平台。所有调用要遵守组织安全模型，Agent 调用工具时要继承同样的权限。

给 Agent 一条明确的成功路径。工具描述、schema、policy、示例、错误返回，都要面向 Agent 重新设计。

把反馈循环做进产品。Agent 的反馈往往比人更具体：它会留下想做什么、试了什么、缺了哪个参数。

上线前能测试，上线后能观测。企业 Agent 的发布流程不能停在 demo。

写在最后

Agent 会让很多旧界面变得不那么重要，也会放大平台型软件的价值。前提是平台愿意把自己打开让 Agent 能用，也愿意把自己管住让 Agent 用得可控。

软件的竞争点可能不再是页面做得多顺，而是这个系统有没有把自己的业务能力讲清楚、管得住、也交得出去。

项目地址：https://github.com/salesforce/agentscript