--- title: "AI 智能体能用你的产品，还是只能读到它？" canonical: https://wavect.io/zh/blog/can-an-ai-agent-use-your-product/ language: zh description: "要让产品对智能体可用而不只是可读，需要什么：委托身份、数据层授权、幂等性、错误语义、MCP 与 agent skills。" image: "https://wavect.io/img/blog/headers/header_can-an-ai-agent-use-your-product.png" author: ["Kevin Riedl"] published: "2026-08-18" updated: "2026-09-02" reviewed: "2026-09-02" --- # AI 智能体能用你的产品，还是只能读到它？ [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 分钟 阅读 · 2026年8月18日 最近审核 2026年9月2日 [**下一篇**](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/) 要点速览 被智能体读懂和被智能体使用是两个不同的项目，而多数团队只做了前一个。可读是指助手能抓取、解析、引用并归属你。可用是指它能以某个具体用户的身份认证、调用工具、改变状态，并在该被拒绝时被拒绝。后者主要是授权、身份和错误语义的问题，而不是模型问题，它的推进节奏取决于你能多精确地说不，因为可读性的 bug 只让你少一次引用，而授权的 bug 会让你多一次事故。一个可用的工具接口需要五样东西：能表达“哪个智能体代表哪个用户、在哪个权限范围内行动”的委托身份；在数据层而不是在 prompt 里执行的授权；幂等键，因为智能体会在自己读错的超时上重试；能指明出错字段的错误信息，好让模型自我修正而不是打转；以及通过 MCP 和公开 agent skills 提供的可发现性。MCP 现在定义了可选的传输层 OAuth 授权，但它不会取代租户与记录范围、审批策略或审计。一个站得住脚的顺序是：先只读工具，再公开一份地图，再把一个低风险写入放到人工审批之后，最后只在审计日志显示行为一贯正确的地方才放宽。目前没人能量化通过智能体带来的收入，所以早期几步的理由在于：它们成本低，而且无论如何都对人类集成有用。 **被智能体读懂，和被智能体使用，是两个不同的项目，而几乎所有团队只做了前一个。**可读，是指助手能总结你、引用你。可用，是指它能代表某个具体的人在你的产品上完成一项任务，并且在该被拦住的时候能被拦住。 后者基本上不是模型问题。它是授权、身份和错误语义的问题，所以它落在工程手里，而不是市场手里。 ## 两个不同的问题 | | 可读 | 可用 | | --- | --- | --- | | 智能体做什么 | 抓取、解析、引用、归属 | 认证、调用、改变状态、回报结果 | | 接口 | HTML、Markdown 镜像、llms.txt、JSON-LD | 带 schema 的工具、身份、权限、审计 | | 失败形态 | 你在答案里缺席 | 发生了本不该发生的事 | | 出错的代价 | 失去注意力 | 失去数据、金钱或信任 | 最后一行正是第二列耗时更久的原因。可读性的 bug 让你少一次引用。授权的 bug 让你多一次事故，所以这项工作的节奏，取决于你能多有把握地说不。 如果第一列还没做完，就先从那里开始。我们的 [智能体可读网站指南](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/) 讲的就是这个，而且工作量只是一小部分。 对于尚未提供工具接口的产品， [ChatGPT 云浏览器的安全登录](/zh/blog/chatgpt-cloud-browser-secure-login/) 是一条实用过渡路径：模型看不到凭据，但已认证会话仍需要低权限账号和受控工作流。它解决的是访问路径，不会替代长期可靠的授权设计。 ## “可用”实际要求什么 一个智能体能操作的工具接口需要五样东西，而其中有意思的那几样并不是 API 本身。 - **不属于智能体自己的身份。** 智能体是代表某个用户或某个租户在行动。如果你的 token 无法表达“这个智能体，代表这个人，在这个权限范围内，到这个时间为止”，那么实际上每一次调用都是管理员调用。 - **在数据层做授权。** 在 prompt 里过滤不是访问控制。边界应该放在查询执行的地方，这样一句有说服力的指令就没法把它撑开。 - **幂等性。** 智能体会重试。它会在自己读错的超时上重试，也会在自己没看懂的部分响应上重试。任何改变状态的调用都需要一个键，让第二次尝试变成空操作。 - **模型能据此行动的错误语义。** 一个只说“请求无效”的 400 会造成重试循环。一个说明哪个字段出错、期望什么形状的 400，会换来一次修正后的调用。这是把文档当成控制面来用。 - **可发现性。** 总得有东西告诉智能体这些工具存在、代价多少、是干什么的。这正是 MCP 和公开发布的 agent skills 在做的事。 ## MCP 该管什么，不该管什么 MCP 提供了一种把工具和资源暴露给模型的标准方式。当前的 [授权规范](https://modelcontextprotocol.io/specification/draft/basic/authorization) 定义了可选的传输层 OAuth 授权，包括绑定目标资源的 token 和受保护资源元数据。但它仍不会决定用户可以读取哪个租户记录、写操作是否需要审批，或审计日志必须保留什么。协议承载这些产品决定，但不替你做决定。 它下面那些设计问题还是老问题。这次调用是给哪个租户的。这个权限范围能看到该租户的哪些记录。谁批准一次写入。要记录什么，才能在事故之后把过程还原出来。这两半我们都写过详细的： [企业级 MCP 授权架构](/zh/blog/enterprise-mcp-authorization-architecture/) 讲多租户参考设计， [MCP 安全边界](/zh/blog/mcp-security-boundary-data-level-access-control/) 讲为什么只有在数据层强制执行才守得住。 Agent skills 位于工具之上，作为指令层：什么时候用哪个工具、内部规则是什么、什么绝对不能做。没有 skills 的工具会被用错；没有工具的 skills 只是建议。我们把自己的 skills 作为带校验和的静态文件公开，任何人都能读到我们对自己的智能体说了什么。 ## 一个不需要信仰的推进顺序 你不需要相信智能体流量会变大，也能证明前两步值得做，因为它们成本低，而且对人类同样有回报。 1. **先做只读工具。** 搜索、查询、状态。没有写入，没有需要设计的审批流程，而且它能在真实条件下把身份和限流跑起来。 2. **把地图发布出去。** 一个 MCP 端点，加上诚实描述这些工具的 skills，包括它们会拒绝什么。 3. **一个写入操作，放在审批之后。** 挑最不危险的那个状态变更，加上幂等键，并在前面放一道人工确认。把一切都记录下来。 4. **按证据放宽。** 只在日志显示智能体一贯正确的那些操作上撤掉审批关卡，其他地方一律保留。 在一个结构清晰的 API 上，第一步和第二步是几天的工作量，而且立刻就有用，因为同样的 schema 和错误信息也会让你自己的集成更省事。第三步才是真正的设计工作所在。 ## 诚实的那部分 今天没有人能告诉你有多少收入是通过智能体来的。谁给你一个数字，谁就是在猜，而我们不替你猜。 能站得住脚的是这场下注的形状。只读接口成本低，标准正在收敛，而且即便智能体流量一直很小，这些工作也没有白做，因为带类型的工具、真实的授权边界和机器可读的错误，本来就是一个成熟 API 应该具备的东西。我们不会做的是：围绕一个还没证明自己的渠道去重建产品。先做那部分无论如何都有用的工作。 ## 常见问题 ### 智能体可读的产品和智能体可用的产品有什么区别？ 可读是指助手能抓取、解析、引用并归属你的内容。可用是指它能以某个具体用户的身份认证、调用工具、改变状态，并在该被拒绝时被拒绝。前者是发布问题，后者是授权与身份问题。 ### 有一个 MCP 服务器，就足以让产品对智能体可用吗？ 不够。MCP 可以提供传输层 OAuth 授权，但租户范围、数据层权限、写入审批和审计日志，仍必须存在于它之后。 ### 为什么智能体需要幂等键？ 因为智能体会重试，包括在它读错的超时上、以及它没看懂的部分响应上重试。如果没有一个让第二次尝试变成空操作的键，一次重试就会变成一笔重复的订单、消息或扣款。 ### 我们能直接把现有的 REST API 暴露出去吗？ 通常可以，但需要两处改动。错误必须说明哪个字段出错、期望什么，这样模型才能自我修正而不是打转。另外权限范围必须能表达“智能体代表某个用户在行动”，而不是一把什么都开着的密钥。 ### 该允许智能体写生产环境吗？ 最终可以，而且要收得很窄。先只读，然后把一个低风险写入放到人工审批之后，配上幂等性和完整日志，只在日志显示行为一贯正确的地方才撤掉这道关卡。 ### 现在投入这件事是不是太早？ 如果是整体重建，太早。如果是只读工具和公开 skills，不早，因为带类型的工具、真实的授权边界和机器可读的错误，无论智能体流量是否增长，都会改善你自己的集成。 ## 最终思考 可读是一个发布问题，靠生成干净副本、放对的抓取器进来，基本就解决了。可用是一个工程问题，它的上限取决于你能多精确地说不。 先把只读接口做出来，因为它无论如何都有回报。然后围绕身份、数据层授权、幂等性和审计去设计写入路径，并按证据而不是按乐观情绪去放宽它。 ## 你可能也喜欢.. [**企业级 MCP 授权架构** 一个厂商中立的多租户参考设计，让你在不扩大爆炸半径的前提下把工具暴露给智能体。](/zh/blog/enterprise-mcp-authorization-architecture/) [**AI Enablement 对比自建 AI 岗位** 什么时候买这个能力、什么时候招人做，以及诚实的盈亏平衡点。](/zh/compare/ai-enablement-vs-in-house-ai-hire/) 选择外部评测服务时，可参考 [Scope 与 Armature API 采用指南](/zh/blog/scope-vs-armature-agent-api-adoption/) ，区分中立发现测试、安装、认证和经验证的任务完成。 智能体工程 ## 接下来读什么 编程智能体、MCP、上下文系统、评估与可靠自动化控制。 [从这里开始**AI 智能体的图工程：知识图谱什么时候值得做？**](/zh/blog/graph-engineering-ai-agents/) - [RTK AI 1.0：实际 Token 节省、安装与许可证](/zh/blog/rtk-ai-token-savings-review/) - [Anatomy Claude Code 技能：用于技术文档的交互式 SVG](/zh/blog/anatomy-claude-code-interactive-svg/) - [Google AX：暂停恢复、重启成本与自托管](/zh/blog/google-ax-agent-executor-security-self-hosting/) - [WikiSkill：智能体如何从经验中进化 SKILL.md](/zh/blog/wikiskill-self-evolving-agent-skills/) - [腾讯 Octop 评测：开发者真正免费获得了什么](/zh/blog/tencent-octop-ai-assistant-review/) [上一篇文章**本地化 URL slug 与 hreflang：为什么我们保留一个英文 slug**](/zh/blog/english-slugs-vs-localized-urls-hreflang/) [下一篇文章**Graft 评测 2026：智能体仓库地图该进 Git 吗？**](/zh/blog/graft-review-agent-repo-map/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 分钟 阅读 · 2026年8月18日 最近审核 2026年9月2日 [**下一篇**](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/)