AI 智能体能用你的产品，还是只能读到它？

被智能体读懂，和被智能体使用，是两个不同的项目，而几乎所有团队只做了前一个。可读，是指助手能总结你、引用你。可用，是指它能代表某个具体的人在你的产品上完成一项任务，并且在该被拦住的时候能被拦住。

后者基本上不是模型问题。它是授权、身份和错误语义的问题，所以它落在工程手里，而不是市场手里。

两个不同的问题

最后一行正是第二列耗时更久的原因。可读性的 bug 让你少一次引用。授权的 bug 让你多一次事故，所以这项工作的节奏，取决于你能多有把握地说不。

如果第一列还没做完，就先从那里开始。我们的智能体可读网站指南讲的就是这个，而且工作量只是一小部分。

“可用”实际要求什么

一个智能体能操作的工具接口需要五样东西，而其中有意思的那几样并不是 API 本身。

• 不属于智能体自己的身份。智能体是代表某个用户或某个租户在行动。如果你的 token 无法表达“这个智能体，代表这个人，在这个权限范围内，到这个时间为止”，那么实际上每一次调用都是管理员调用。
• 在数据层做授权。在 prompt 里过滤不是访问控制。边界应该放在查询执行的地方，这样一句有说服力的指令就没法把它撑开。
• 幂等性。智能体会重试。它会在自己读错的超时上重试，也会在自己没看懂的部分响应上重试。任何改变状态的调用都需要一个键，让第二次尝试变成空操作。
• 模型能据此行动的错误语义。一个只说“请求无效”的 400 会造成重试循环。一个说明哪个字段出错、期望什么形状的 400，会换来一次修正后的调用。这是把文档当成控制面来用。
• 可发现性。总得有东西告诉智能体这些工具存在、代价多少、是干什么的。这正是 MCP 和公开发布的 agent skills 在做的事。

MCP 该管什么，不该管什么

MCP 给了你一种把工具和资源暴露给模型的标准方式，它是正确的传输层。它不是授权模型，而把它当成授权模型，是这个领域里最常见的错误。协议承载你的决定，但不替你做决定。

它下面那些设计问题还是老问题。这次调用是给哪个租户的。这个权限范围能看到该租户的哪些记录。谁批准一次写入。要记录什么，才能在事故之后把过程还原出来。这两半我们都写过详细的：企业级 MCP 授权架构讲多租户参考设计，MCP 安全边界讲为什么只有在数据层强制执行才守得住。

Agent skills 位于工具之上，作为指令层：什么时候用哪个工具、内部规则是什么、什么绝对不能做。没有 skills 的工具会被用错；没有工具的 skills 只是建议。我们把自己的 skills 作为带校验和的静态文件公开，任何人都能读到我们对自己的智能体说了什么。

一个不需要信仰的推进顺序

你不需要相信智能体流量会变大，也能证明前两步值得做，因为它们成本低，而且对人类同样有回报。

1. 先做只读工具。搜索、查询、状态。没有写入，没有需要设计的审批流程，而且它能在真实条件下把身份和限流跑起来。
2. 把地图发布出去。一个 MCP 端点，加上诚实描述这些工具的 skills，包括它们会拒绝什么。
3. 一个写入操作，放在审批之后。挑最不危险的那个状态变更，加上幂等键，并在前面放一道人工确认。把一切都记录下来。
4. 按证据放宽。只在日志显示智能体一贯正确的那些操作上撤掉审批关卡，其他地方一律保留。

在一个结构清晰的 API 上，第一步和第二步是几天的工作量，而且立刻就有用，因为同样的 schema 和错误信息也会让你自己的集成更省事。第三步才是真正的设计工作所在。

诚实的那部分

今天没有人能告诉你有多少收入是通过智能体来的。谁给你一个数字，谁就是在猜，而我们不替你猜。

能站得住脚的是这场下注的形状。只读接口成本低，标准正在收敛，而且即便智能体流量一直很小，这些工作也没有白做，因为带类型的工具、真实的授权边界和机器可读的错误，本来就是一个成熟 API 应该具备的东西。我们不会做的是：围绕一个还没证明自己的渠道去重建产品。先做那部分无论如何都有用的工作。