--- 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" --- [**返回**](/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年8月18日 [**下一篇**](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/) # AI 智能体能用你的产品，还是只能读到它？ 要点速览 被智能体读懂和被智能体使用是两个不同的项目，而多数团队只做了前一个。可读是指助手能抓取、解析、引用并归属你。可用是指它能以某个具体用户的身份认证、调用工具、改变状态，并在该被拒绝时被拒绝。后者主要是授权、身份和错误语义的问题，而不是模型问题，它的推进节奏取决于你能多精确地说不，因为可读性的 bug 只让你少一次引用，而授权的 bug 会让你多一次事故。一个可用的工具接口需要五样东西：能表达“哪个智能体代表哪个用户、在哪个权限范围内行动”的委托身份；在数据层而不是在 prompt 里执行的授权；幂等键，因为智能体会在自己读错的超时上重试；能指明出错字段的错误信息，好让模型自我修正而不是打转；以及通过 MCP 和公开 agent skills 提供的可发现性。MCP 是传输层，不是授权模型，把它当成授权模型是常见错误。一个站得住脚的顺序是：先只读工具，再公开一份地图，再把一个低风险写入放到人工审批之后，最后只在审计日志显示行为一贯正确的地方才放宽。目前没人能量化通过智能体带来的收入，所以早期几步的理由在于：它们成本低，而且无论如何都对人类集成有用。 **被智能体读懂，和被智能体使用，是两个不同的项目，而几乎所有团队只做了前一个。**可读，是指助手能总结你、引用你。可用，是指它能代表某个具体的人在你的产品上完成一项任务，并且在该被拦住的时候能被拦住。 后者基本上不是模型问题。它是授权、身份和错误语义的问题，所以它落在工程手里，而不是市场手里。 ## 两个不同的问题 | | 可读 | 可用 | | --- | --- | --- | | 智能体做什么 | 抓取、解析、引用、归属 | 认证、调用、改变状态、回报结果 | | 接口 | HTML、Markdown 镜像、llms.txt、JSON-LD | 带 schema 的工具、身份、权限、审计 | | 失败形态 | 你在答案里缺席 | 发生了本不该发生的事 | | 出错的代价 | 失去注意力 | 失去数据、金钱或信任 | 最后一行正是第二列耗时更久的原因。可读性的 bug 让你少一次引用。授权的 bug 让你多一次事故，所以这项工作的节奏，取决于你能多有把握地说不。 如果第一列还没做完，就先从那里开始。我们的 [智能体可读网站指南](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/) 讲的就是这个，而且工作量只是一小部分。 ## “可用”实际要求什么 一个智能体能操作的工具接口需要五样东西，而其中有意思的那几样并不是 API 本身。 - **不属于智能体自己的身份。** 智能体是代表某个用户或某个租户在行动。如果你的 token 无法表达“这个智能体，代表这个人，在这个权限范围内，到这个时间为止”，那么实际上每一次调用都是管理员调用。 - **在数据层做授权。** 在 prompt 里过滤不是访问控制。边界应该放在查询执行的地方，这样一句有说服力的指令就没法把它撑开。 - **幂等性。** 智能体会重试。它会在自己读错的超时上重试，也会在自己没看懂的部分响应上重试。任何改变状态的调用都需要一个键，让第二次尝试变成空操作。 - **模型能据此行动的错误语义。** 一个只说“请求无效”的 400 会造成重试循环。一个说明哪个字段出错、期望什么形状的 400，会换来一次修正后的调用。这是把文档当成控制面来用。 - **可发现性。** 总得有东西告诉智能体这些工具存在、代价多少、是干什么的。这正是 MCP 和公开发布的 agent skills 在做的事。 ## MCP 该管什么，不该管什么 MCP 给了你一种把工具和资源暴露给模型的标准方式，它是正确的传输层。它不是授权模型，而把它当成授权模型，是这个领域里最常见的错误。协议承载你的决定，但不替你做决定。 它下面那些设计问题还是老问题。这次调用是给哪个租户的。这个权限范围能看到该租户的哪些记录。谁批准一次写入。要记录什么，才能在事故之后把过程还原出来。这两半我们都写过详细的： [企业级 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 是暴露工具和资源的传输层，它承载你的授权决定，而不是替你做决定。租户范围、数据层权限、写入审批和审计日志，都必须存在于它之后。 ### 为什么智能体需要幂等键？ 因为智能体会重试，包括在它读错的超时上、以及它没看懂的部分响应上重试。如果没有一个让第二次尝试变成空操作的键，一次重试就会变成一笔重复的订单、消息或扣款。 ### 我们能直接把现有的 REST API 暴露出去吗？ 通常可以，但需要两处改动。错误必须说明哪个字段出错、期望什么，这样模型才能自我修正而不是打转。另外权限范围必须能表达“智能体代表某个用户在行动”，而不是一把什么都开着的密钥。 ### 该允许智能体写生产环境吗？ 最终可以，而且要收得很窄。先只读，然后把一个低风险写入放到人工审批之后，配上幂等性和完整日志，只在日志显示行为一贯正确的地方才撤掉这道关卡。 ### 现在投入这件事是不是太早？ 如果是整体重建，太早。如果是只读工具和公开 skills，不早，因为带类型的工具、真实的授权边界和机器可读的错误，无论智能体流量是否增长，都会改善你自己的集成。 ## 最终思考 可读是一个发布问题，靠生成干净副本、放对的抓取器进来，基本就解决了。可用是一个工程问题，它的上限取决于你能多精确地说不。 先把只读接口做出来，因为它无论如何都有回报。然后围绕身份、数据层授权、幂等性和审计去设计写入路径，并按证据而不是按乐观情绪去放宽它。 ## 你可能也喜欢.. [**企业级 MCP 授权架构** 一个厂商中立的多租户参考设计，让你在不扩大爆炸半径的前提下把工具暴露给智能体。](/zh/blog/enterprise-mcp-authorization-architecture/) [**AI Enablement 对比自建 AI 岗位** 什么时候买这个能力、什么时候招人做，以及诚实的盈亏平衡点。](/zh/compare/ai-enablement-vs-in-house-ai-hire/) 智能体工程 ## 继续浏览此集群 编程智能体、MCP、上下文系统、评估与可靠自动化控制。 [从核心文章开始**AI 智能体的图工程：知识图谱什么时候值得做？**](/zh/blog/graph-engineering-ai-agents/) - [智能体可读的网站：llms.txt、Markdown 镜像，以及会坏在哪里](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/) - [本地化 URL 会搞坏 hreflang：只保留一个英文 slug](/zh/blog/english-slugs-vs-localized-urls-hreflang/) - [Graft 评测 2026：智能体仓库地图该进 Git 吗？](/zh/blog/graft-review-agent-repo-map/) - [通过工具输出压缩降低编码代理成本](/zh/blog/codag-cost-control/) - [用 AI 编码智能体更聪明地管理 Token](/zh/blog/smarter-token-usage-with-your-ai-coding-agent/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/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年8月18日 [**下一篇**](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/can-an-ai-agent-use-your-product/#webpage", "@type": "WebPage", "dateModified": "2026-08-18", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-18", "url": "https://wavect.io/zh/blog/can-an-ai-agent-use-your-product/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "被智能体读懂和被智能体使用是两个不同的项目，而多数团队只做了前一个。可读是指助手能抓取、解析、引用并归属你。可用是指它能以某个具体用户的身份认证、调用工具、改变状态，并在该被拒绝时被拒绝。后者主要是授权、身份和错误语义的问题，而不是模型问题，它的推进节奏取决于你能多精确地说不，因为可读性的 bug 只让你少一次引用，而授权的 bug 会让你多一次事故。一个可用的工具接口需要五样东西：能表达“哪个智能体代表哪个用户、在哪个权限范围内行动”的委托身份；在数据层而不是在 prompt 里执行的授权；幂等键，因为智能体会在自己读错的超时上重试；能指明出错字段的错误信息，好让模型自我修正而不是打转；以及通过 MCP 和公开 agent skills 提供的可发现性。MCP 是传输层，不是授权模型，把它当成授权模型是常见错误。一个站得住脚的顺序是：先只读工具，再公开一份地图，再把一个低风险写入放到人工审批之后，最后只在审计日志显示行为一贯正确的地方才放宽。目前没人能量化通过智能体带来的收入，所以早期几步的理由在于：它们成本低，而且无论如何都对人类集成有用。", "articleBody": " 博客概览/AI 与智能体/智能体工程 AI 智能体能用你的产品，还是只能读到它？ 要点速览 被智能体读懂和被智能体使用是两个不同的项目，而多数团队只做了前一个。可读是指助手能抓取、解析、引用并归属你。可用是指它能以某个具体用户的身份认证、调用工具、改变状态，并在该被拒绝时被拒绝。后者主要是授权、身份和错误语义的问题，而不是模型问题，它的推进节奏取决于你能多精确地说不，因为可读性的 bug 只让你少一次引用，而授权的 bug 会让你多一次事故。一个可用的工具接口需要五样东西：能表达“哪个智能体代表哪个用户、在哪个权限范围内行动”的委托身份；在数据层而不是在 prompt 里执行的授权；幂等键，因为智能体会在自己读错的超时上重试；能指明出错字段的错误信息，好让模型自我修正而不是打转；以及通过 MCP 和公开 agent skills 提供的可发现性。MCP 是传输层，不是授权模型，把它当成授权模型是常见错误。一个站得住脚的顺序是：先只读工具，再公开一份地图，再把一个低风险写入放到人工审批之后，最后只在审计日志显示行为一贯正确的地方才放宽。目前没人能量化通过智能体带来的收入，所以早期几步的理由在于：它们成本低，而且无论如何都对人类集成有用。 被智能体读懂，和被智能体使用，是两个不同的项目，而几乎所有团队只做了前一个。可读，是指助手能总结你、引用你。可用，是指它能代表某个具体的人在你的产品上完成一项任务，并且在该被拦住的时候能被拦住。 后者基本上不是模型问题。它是授权、身份和错误语义的问题，所以它落在工程手里，而不是市场手里。 两个不同的问题 可读可用 智能体做什么抓取、解析、引用、归属认证、调用、改变状态、回报结果 接口HTML、Markdown 镜像、llms.txt、JSON-LD带 schema 的工具、身份、权限、审计 失败形态你在答案里缺席发生了本不该发生的事 出错的代价失去注意力失去数据、金钱或信任 最后一行正是第二列耗时更久的原因。可读性的 bug 让你少一次引用。授权的 bug 让你多一次事故，所以这项工作的节奏，取决于你能多有把握地说不。 如果第一列还没做完，就先从那里开始。我们的智能体可读网站指南讲的就是这个，而且工作量只是一小部分。 “可用”实际要求什么 一个智能体能操作的工具接口需要五样东西，而其中有意思的那几样并不是 API 本身。 不属于智能体自己的身份。智能体是代表某个用户或某个租户在行动。如果你的 token 无法表达“这个智能体，代表这个人，在这个权限范围内，到这个时间为止”，那么实际上每一次调用都是管理员调用。 在数据层做授权。在 prompt 里过滤不是访问控制。边界应该放在查询执行的地方，这样一句有说服力的指令就没法把它撑开。 幂等性。智能体会重试。它会在自己读错的超时上重试，也会在自己没看懂的部分响应上重试。任何改变状态的调用都需要一个键，让第二次尝试变成空操作。 模型能据此行动的错误语义。一个只说“请求无效”的 400 会造成重试循环。一个说明哪个字段出错、期望什么形状的 400，会换来一次修正后的调用。这是把文档当成控制面来用。 可发现性。总得有东西告诉智能体这些工具存在、代价多少、是干什么的。这正是 MCP 和公开发布的 agent skills 在做的事。 MCP 该管什么，不该管什么 MCP 给了你一种把工具和资源暴露给模型的标准方式，它是正确的传输层。它不是授权模型，而把它当成授权模型，是这个领域里最常见的错误。协议承载你的决定，但不替你做决定。 它下面那些设计问题还是老问题。这次调用是给哪个租户的。这个权限范围能看到该租户的哪些记录。谁批准一次写入。要记录什么，才能在事故之后把过程还原出来。这两半我们都写过详细的：企业级 MCP 授权架构讲多租户参考设计，MCP 安全边界讲为什么只有在数据层强制执行才守得住。 Agent skills 位于工具之上，作为指令层：什么时候用哪个工具、内部规则是什么、什么绝对不能做。没有 skills 的工具会被用错；没有工具的 skills 只是建议。我们把自己的 skills 作为带校验和的静态文件公开，任何人都能读到我们对自己的智能体说了什么。 一个不需要信仰的推进顺序 你不需要相信智能体流量会变大，也能证明前两步值得做，因为它们成本低，而且对人类同样有回报。 先做只读工具。搜索、查询、状态。没有写入，没有需要设计的审批流程，而且它能在真实条件下把身份和限流跑起来。 把地图发布出去。一个 MCP 端点，加上诚实描述这些工具的 skills，包括它们会拒绝什么。 一个写入操作，放在审批之后。挑最不危险的那个状态变更，加上幂等键，并在前面放一道人工确认。把一切都记录下来。 按证据放宽。只在日志显示智能体一贯正确的那些操作上撤掉审批关卡，其他地方一律保留。 在一个结构清晰的 API 上，第一步和第二步是几天的工作量，而且立刻就有用，因为同样的 schema 和错误信息也会让你自己的集成更省事。第三步才是真正的设计工作所在。 诚实的那部分 今天没有人能告诉你有多少收入是通过智能体来的。谁给你一个数字，谁就是在猜，而我们不替你猜。 能站得住脚的是这场下注的形状。只读接口成本低，标准正在收敛，而且即便智能体流量一直很小，这些工作也没有白做，因为带类型的工具、真实的授权边界和机器可读的错误，本来就是一个成熟 API 应该具备的东西。我们不会做的是：围绕一个还没证明自己的渠道去重建产品。先做那部分无论如何都有用的工作。 常见问题 智能体可读的产品和智能体可用的产品有什么区别？ 可读是指助手能抓取、解析、引用并归属你的内容。可用是指它能以某个具体用户的身份认证、调用工具、改变状态，并在该被拒绝时被拒绝。前者是发布问题，后者是授权与身份问题。 有一个 MCP 服务器，就足以让产品对智能体可用吗？ 不够。MCP 是暴露工具和资源的传输层，它承载你的授权决定，而不是替你做决定。租户范围、数据层权限、写入审批和审计日志，都必须存在于它之后。 为什么智能体需要幂等键？ 因为智能体会重试，包括在它读错的超时上、以及它没看懂的部分响应上重试。如果没有一个让第二次尝试变成空操作的键，一次重试就会变成一笔重复的订单、消息或扣款。 我们能直接把现有的 REST API 暴露出去吗？ 通常可以，但需要两处改动。错误必须说明哪个字段出错、期望什么，这样模型才能自我修正而不是打转。另外权限范围必须能表达“智能体代表某个用户在行动”，而不是一把什么都开着的密钥。 该允许智能体写生产环境吗？ 最终可以，而且要收得很窄。先只读，然后把一个低风险写入放到人工审批之后，配上幂等性和完整日志，只在日志显示行为一贯正确的地方才撤掉这道关卡。 现在投入这件事是不是太早？ 如果是整体重建，太早。如果是只读工具和公开 skills，不早，因为带类型的工具、真实的授权边界和机器可读的错误，无论智能体流量是否增长，都会改善你自己的集成。 最终思考 可读是一个发布问题，靠生成干净副本、放对的抓取器进来，基本就解决了。可用是一个工程问题，它的上限取决于你能多精确地说不。先把只读接口做出来，因为它无论如何都有回报。然后围绕身份、数据层授权、幂等性和审计去设计写入路径，并按证据而不是按乐观情绪去放宽它。 你可能也喜欢.. 企业级 MCP 授权架构 一个厂商中立的多租户参考设计，让你在不扩大爆炸半径的前提下把工具暴露给智能体。 AI Enablement 对比自建 AI 岗位 什么时候买这个能力、什么时候招人做，以及诚实的盈亏平衡点。 智能体工程 继续浏览此集群 编程智能体、MCP、上下文系统、评估与可靠自动化控制。 从核心文章开始AI 智能体的图工程：知识图谱什么时候值得做？ 智能体可读的网站：llms.txt、Markdown 镜像，以及会坏在哪里 本地化 URL 会搞坏 hreflang：只保留一个英文 slug Graft 评测 2026：智能体仓库地图该进 Git 吗？ 通过工具输出压缩降低编码代理成本 用 AI 编码智能体更聪明地管理 Token 集群中的上一篇本地化 URL 会搞坏 hreflang：只保留一个英文 slug集群中的下一篇Graft 评测 2026：智能体仓库地图该进 Git 吗？ 相关服务路径： AI 可见性 看看生产环境中的应用: 债券分析平台 先做决定: 如何挑选软件开发公司 只收重要内容 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 Company 电子邮箱 你希望接收哪些内容？ 完整的 Wavect 博客接收六个主题下的每一篇新文章。 仅接收所选主题请在下方选择一个或多个分类。 选择主题 AI 与智能体 产品与 MVP 交付与 QA 领导力与团队 商业与监管 Web3 与隐私 我希望接收所选的 Wavect 博客邮件，并已阅读 隐私信息。我可以随时退订。 发送确认邮件→ 免费、双重确认、不使用跟踪像素。 ", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-08-18", "datePublished": "2026-08-18", "description": "被智能体读懂和被智能体使用是两个不同的项目，而多数团队只做了前一个。可读是指助手能抓取、解析、引用并归属你。可用是指它能以某个具体用户的身份认证、调用工具、改变状态，并在该被拒绝时被拒绝。后者主要是授权、身份和错误语义的问题，而不是模型问题，它的推进节奏取决于你能多精确地说不，因为可读性的 bug 只让你少一次引用，而授权的 bug 会让你多一次事故。一个可用的工具接口需要五样东西：能表达“哪个智能体代表哪个用户、在哪个权限范围内行动”的委托身份；在数据层而不是在 prompt 里执行的授权；幂等键，因为智能体会在自己读错的超时上重试；能指明出错字段的错误信息，好让模型自我修正而不是打转；以及通过 MCP 和公开 agent skills 提供的可发现性。MCP 是传输层，不是授权模型，把它当成授权模型是常见错误。一个站得住脚的顺序是：先只读工具，再公开一份地图，再把一个低风险写入放到人工审批之后，最后只在审计日志显示行为一贯正确的地方才放宽。目前没人能量化通过智能体带来的收入，所以早期几步的理由在于：它们成本低，而且无论如何都对人类集成有用。", "headline": "AI 智能体能用你的产品，还是只能读到它？", "image": "https://wavect.io/img/blog/headers/header_can-an-ai-agent-use-your-product.svg", "inLanguage": "zh", "keywords": "AI 可见性, MCP", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/can-an-ai-agent-use-your-product/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/can-an-ai-agent-use-your-product/", "wordCount": 192 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/agent-engineering/", "name": "智能体工程", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/can-an-ai-agent-use-your-product/", "name": "AI 智能体能用你的产品，还是只能读到它？ | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "可读是指助手能抓取、解析、引用并归属你的内容。可用是指它能以某个具体用户的身份认证、调用工具、改变状态，并在该被拒绝时被拒绝。前者是发布问题，后者是授权与身份问题。" }, "name": "智能体可读的产品和智能体可用的产品有什么区别？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不够。MCP 是暴露工具和资源的传输层，它承载你的授权决定，而不是替你做决定。租户范围、数据层权限、写入审批和审计日志，都必须存在于它之后。" }, "name": "有一个 MCP 服务器，就足以让产品对智能体可用吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "因为智能体会重试，包括在它读错的超时上、以及它没看懂的部分响应上重试。如果没有一个让第二次尝试变成空操作的键，一次重试就会变成一笔重复的订单、消息或扣款。" }, "name": "为什么智能体需要幂等键？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "通常可以，但需要两处改动。错误必须说明哪个字段出错、期望什么，这样模型才能自我修正而不是打转。另外权限范围必须能表达“智能体代表某个用户在行动”，而不是一把什么都开着的密钥。" }, "name": "我们能直接把现有的 REST API 暴露出去吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "最终可以，而且要收得很窄。先只读，然后把一个低风险写入放到人工审批之后，配上幂等性和完整日志，只在日志显示行为一贯正确的地方才撤掉这道关卡。" }, "name": "该允许智能体写生产环境吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "如果是整体重建，太早。如果是只读工具和公开 skills，不早，因为带类型的工具、真实的授权边界和机器可读的错误，无论智能体流量是否增长，都会改善你自己的集成。" }, "name": "现在投入这件事是不是太早？" } ] } ```