网站通常为人阅读，但 Agent 也在成为新的访问者。我们想解决的不是给网页加一个聊天框，而是一个更基础的问题：怎样让同一份公开内容既能被访客完整阅读，也能由 Agent 以明确、受约束的方式发现和读取？

为什么可阅读的网页还不够

对人来说，目录、卡片和文章页已经构成自然的阅读路径；对 Agent 来说，仅靠页面浏览仍可能缺少稳定的查询入口。它需要知道有哪些内容、如何检索，以及怎样按稳定 ID 取得全文。网页负责呈现，工具负责提供边界清楚的读取动作，两者应当互补。

一个内容源，同时服务人和 Agent

内容库把每篇内容记录为公开数据：稳定 ID、主题、双语标题与摘要、原始语言、发布日期、正文版本、正文块和适用的来源。构建过程从同一份数据生成目录、全文页与工具读取模块，降低分别维护网页和接口时发生内容漂移的可能。

三个最小的只读动作

list_content 列出最新内容与公开元数据，不返回正文；search_content 在标题、摘要和中文正文中做本地子串匹配，返回匹配片段；read_content 根据稳定 ID 返回完整公开文字。它们不导航、不写入、不保存查询，也不向外部平台发起运行时请求。

这里刻意不把搜索描述成语义检索。能力名称应与实际实现一致：简单、可预期的子串匹配已经足以支持内容发现，也让结果更容易解释。

可验证具体意味着什么

一篇内容至少应能回答五个问题：它是哪一篇、正文是什么版本、何时首次公开、适用的出处在哪里、规范网页地址是什么。平台迁移文字继续保留各自来源和日期；站内首发文章则明确标记为官网原创，不为它虚构外部来源。

为什么从只读开始

只读能力把价值和风险控制在一个清楚的范围内：Agent 可以发现、检索和引用公开内容，却不能借这些工具改变页面、账户或外部系统。readOnlyHint 用于声明工具意图，真正的边界仍由输入限制、公开字段投影和无写入实现共同保证。

工具不可用时，网页仍应成立

WebMCP 是渐进增强，而不是阅读的前置条件。支持相应能力的环境可以发现工具；不支持或注册失败时，访客仍能通过普通静态网页浏览目录和全文。这样既保留开放网页的可访问性，也为 Agent 增加一条结构化入口。

这次实践留下的三个原则

第一，先让内容本身完整、公开、可阅读；第二，让网页与工具共享同一份公开事实；第三，让版本、来源和能力边界一样清楚。对我们而言，Agent 友好的网站不是用对话界面替代页面，而是在可靠网页之上，提供少量可理解、可调用、可退化的工具。