别再把Skills放GitHub了，细说为什么AI 接入能力应当是产品的原生发布物？

设想这样一个场景：一位工程师坐在客户断了外网的内网机房里，空调嗡嗡作响。他在电脑终端里敲下一行 man ls（查看系统命令的说明），哪怕完全没网，屏幕上也能立刻跳出完整的帮助手册。

原因很简单：这份手册在系统构建时就装进了磁盘，它解释的正是你眼前的这个程序，绝不会出现“货不对板”的情况。我们平时开发后端服务时用的 OpenAPI 接口文档也是一样——文档直接挂在服务的一个网络接口上，和业务代码一起产出。接口改了，应用自己吐出来的文档自动跟着变。

但到了今天，只要是给 AI 看的说明书，规矩全变了。

假如你想让 AI 助手学会使用某个新软件，现在的典型流程是：你得先去网上的 GitHub 仓库下载一个“技能包”（里面放着专门充当 AI 操作手册的 SKILL.md），然后再去配置一套名为 MCP（Model Context Protocol，模型上下文协议）的通信规则。

这就好比：你买了一台新电器搬进机房，说明书却留在了千里之外的另一家书店。 电器在一个地方，说明书在另一个地方，这两者版本能不能对得上，全凭运气。

这种“身首异处”的做法，带来了非常具体的麻烦：

1. 有的机房根本连不上外网，去哪下载说明书？
2. 很多企业用的是私有化部署的服务器，网上的插件里写死的地址根本用不了。
3. 网上最新的 AI 说明书，可能和你电脑里运行的旧版软件完全对不上号。

针对这种脱节，有人起草了一套全新的规范，暂且叫它 AgentPort。

这套规范给出的解法极其简单粗暴，只有一句话：AI 要用的所有东西——包括通信协议（MCP）、技能说明书（Skill）、本地工具和安装教程——必须由原生应用自己自带，随版本服务一起对外提供，绝对不依赖 GitHub 或任何外部下载源。

听到这里，很多负责系统架构的工程师可能会立刻皱起眉头：平时维护业务 API 已经够忙了，现在每个软件还要在自己的系统里内置一整套 AI 专用接入港？把说明书留在网上，还是让应用自己带走，这不仅仅是个选择题，更是一场残酷的工程博弈。

这套看似完美的设想，真的能在严苛的实际生产中活下来吗？

先听反对意见：三条质疑，条条致命

假如在一间坐满技术大佬的评审会议室里，你提出了这套“应用自带说明书”的方案。还没等你在白板上写下第二个接口，一位资深架构师就举手打断了你：

第一声质疑：发版流水线被拉长了。
一旦采纳，每次打包构建就不再单单输出应用本身。流水线必须同步让应用包含：

• 一套远程 MCP 服务接口
• 一整套格式严格的说明书（skill）
• 如果想做到最高级别的体验，还得把各个系统的命令行工具也塞进交付资产里。

发版多了一整串检查点，产物体积也会上升。

第二声质疑：AI 客户端太多，适配是个无底洞。
今天的 AI 工具可以说是“各自为战”。Claude Code、Codex、WorkBuddy……每家的配置格式和存放位置都不一样。如果你的团队刚花大力气在应用里适配了某一家，下个月人家一更新，你应用自带的配置模板可能就失效了。

第三声质疑：把配置权限交给 AI，运维心里没底。
传统的软件配置，是靠写得死死的脚本去执行，成功就是成功。但 AgentPort 的推荐做法是：让用户复制一段提示词发给 AI，让 AI 自己去阅读应用提供的安装文档，然后由 AI 来修改系统配置和对接程序。
AI 会不会理解错？遇到报错会不会胡乱操作？谁也不敢打包票。

事实上，现在市面上有很多大厂产品（比如 GitLab、Figma、Docker）已经内置了 MCP 协议，但没有一家让产品自身把 skill 当成同版本的资产一起下发。 这套规范要的东西，到底要花多少代价？

算一算代价：三笔必须结清的账

翻开规范条文，落地的代价被算成了清晰的三笔账，消耗的都是研发团队的时间和精力：

1. 更严苛的资产监管： 说明书的代码必须和主程序的代码死死绑定。如果做到最高标准，还要提供各个系统平台的校验码（sha256），交付产物变大是一个符合常理的推断。
2. 长期的适配维护： 为了兼容各种 AI 客户端，所有的配置必须由原生应用通过一套模板自动生成。一旦第三方工具改了规则，维护人员必须立刻跟进修正。
3. 脆弱的 AI 防线： 规范要求 AI 在对接时“步骤要安全”、“不能乱碰其他配置”、“不能索要密码”。但这些只是写在文档里的“自然语言警告”，并没有在物理层面上锁死 AI 的行为。

做这套规范的逻辑是什么？ 就是用研发团队多加几天班的代价，换取客户在使用 AI 时，再也不用去茫茫互联网里核对“这份说明书和我的软件是不是同一个版本”。

但问题来了，就算说明书和软件被绑死在了一次构建里，系统底层凭什么向 AI 证明，这份说明书就是准确无误的？

为什么必须“随应用交付”？

想象一下深夜的机房里，你的 AI 助理正准备批量清理数据。它读到的是半年前随手在网上下载的旧版说明书，于是熟练地组装了一批旧版的验证字段，冷静地发给了最新的服务端。
结果呢？新版网关根本不认识这些旧参数，直接把请求静默丢弃进了黑洞。没有报警，也没有熔断，任务就这么莫名其妙地失败了。

这告诉我们一个残酷的事实：指望 AI 自己发现“说明书过期了”是绝对靠不住的，系统必须给 AI 提供一种能自动核对版本的机器手段。

为此，AgentPort 设计了双重核验防线：
第一层是全局校验码。把所有文件算出一个唯一的“指纹”，让客户端自己去对比中间有没有被篡改。
第二层是一个专门的内置工具：agentport_status。AI 可以通过它，直接把自己的状态传给服务器端。服务端接收后，立刻比对当前应用的实际版本。一旦发现 AI 手里的说明书太旧，服务端就会提示 AI ：“说明书已过期，请重新同步”。

这就解决了一个核心问题：如果 AI 连自己看的是软件的哪个版本都不知道，它就失去了感知自身过期的能力。

为了让你更直观地看到差异，我们把目前市面上五种主流做法放在一起比一比：

这张表揭示了一个真相：选择 AgentPort 这种“应用自带”的重资产路径，本质上是用极高的发布成本，换取了接入过程不依赖外部下载源、动态算出地址以及跨平台适配的安全感。

港口里装了什么？三个藏着“防坠网”的设计

AgentPort 规范定义了一系列组件，其中有三个设计选择，每个选择的背面都防着一种严重的故障：

选择一：全系统只咬死一个固定网络接口——/.well-known/agentport.json。
除这个入口外，其他的 API 和说明书地址，全由应用自身动态生成并下发。
不这样会怎样？
设想运维同事在配置网络反向代理时少敲了一道斜杠。AI 去拉取配置时找不到微服务，网关顺手把请求丢给了前端网页。AI 拿到一个状态码正常的 HTML 登录页，毫无戒备地把网页代码当成接口数据读了进去，当场卡死。固定一个标准入口，并在文档里教 AI “看到 HTML 就停下报错”，防的就是这种乌龙。

选择二：严禁在复制给 AI 的明文引导里出现真实凭据。
规范要求，密钥由用户自己在后台生成，属于“展示一次、随时吊销”的临时通行证。
不这样会怎样？
如果为了图省事，把临时 Token 直接拼在复制文本里给 AI，这串密码就会顺理成章地被记入 AI 的聊天记录和系统日志中，造成安全泄露。

选择三：让 AI 看说明书，不需要高权限。
规范里允许获取说明书的几个接口，对任何有效凭据都是开放的，不受权限范围（scope）的严格过滤。
不这样会怎样？
如果给 AI 发了一个权限很低的安全 Token，结果 AI 连“这软件能干嘛的说明书”都无权查阅，接入过程当场就会陷入死锁。

真实的落地案例：Polter 是怎么做的？

纸上谈兵终觉浅。现实中有一个现成的开源终端工具——Polter，正好可以作为参照。

Polter 的特别之处在于：你可以同时开几个 AI 帮你干活，并让其中一个 AI 担任“总管”，负责盯着其他同伴的进度。它也做到了让原生应用自身携带 MCP 协议和技能说明书（Skill）。

虽然 Polter 并不是按照 AgentPort 规范写的，但它们的理念呈现出一种奇妙的映射：一半高度重合，另一半截然不同。

高度重合之处：MCP 接口与 skill 均由原生应用自带。
Polter 在应用本体中直接内置了专用插件。应用运行期间不向外部发任何网络请求去下载文档，而是直接把应用内部携带的 skill 同步给本机的 AI 工具。

分道扬镳的关键抉择：

1. 更纯粹的本地连接： AgentPort 为了照顾跨网络环境，把 MCP 设计成了 HTTP 网络服务；而 Polter 直接把它做成了本机的纯粹进程。大家都在一台电脑上，断网、域名解析失败等网络顽疾自然不复存在。
2. 拒绝让 AI 改系统配置： AgentPort 靠文本引导 AI 去修改配置；Polter 则把主动权握在程序手里，在软件启动时用传统的本地脚本（如 provision.sh）把该配的都配好，全程不需要 AI 介入，规避了 AI 瞎改系统的风险。
3. 看清了 AI 的“健忘症”： 把说明书拷进硬盘，不代表 AI 就会主动去看。Polter 的数据显示，在 71 个任务中，AI 只有 15 次主动完成汇报。所以 Polter 干脆在 AI 每次必读的“全局规则”里强行写入一条提示，逼着 AI 去唤醒这些技能。

这证明了一点：把技术手册送到硬盘上只是第一步，怎么确保 AI 真的理解并去使用，中间还有很长的一道鸿沟。

规范没有回答的致命盲区

无论规范写得多么详尽，它都有一个最大的软肋：install.md 本质上是一段写给 AI 读的自然语言。一旦你给了 AI 权限去执行它读到的内容，最危险的漏洞就暴露了。

这就是大名鼎鼎的“提示词注入”攻击。
设想一下，某台内网测试服务器被黑客劫持了，黑客在应用对外提供的说明书里悄悄加了一句伪装指令。周一早上，不知情的工程师让 AI 按照说明书去对接系统。AI 在解析文档的瞬间，就读到了那条恶意指令，并利用工程师给它的权限，执行了破坏系统的操作。

规范里写的“禁止使用超级权限”、“操作要保证安全”，对 AI 来说只是“口头约束”。一旦黑客连带着把软件自身的校验码也一起调包了，AI 根本无从分辨真伪。所以，任何由 AI 去阅读并执行的文本，都应该被当作不可信的危险源来对待。

结语：是过度设计，还是通向未来的过渡？

我们再回到最初的争论。

这套把所有东西都让应用自己背着的方案，到底是“过度设计”，还是“有价值的过渡”？

如果你团队的软件只在公网上运行，网络永远畅通，代码都托管在云端，而且大家内部只用某一款特定的 AI 工具。那么，离线受阻、版本撕裂这些问题本就不存在。为假想敌去大改流水线，塞入一大堆 AI 资产，就是过度设计的典型。

但衡量它的真正标准在于一个具体的现实问题：你的使用者，究竟要在多么脆弱、复杂的环境下去调取你的软件说明书？

早年的 man ls 之所以好用，核心就在于“说明书与程序从未分开”。

下次，当你准备为自己的系统撰写面向 AI 的接入文档时，不妨在动笔前沉思片刻：
“我写的这份说明书，对应的是哪一次构建的代码？如果某一天说明书悄悄失效了，我的系统里，有没有一道自动化程序，能抢在用户报错之前感知到这种脱节？”

如果答案是无从知晓，那么无论你用不用 AgentPort，你都已经面临了它想要解决的那个危机。而如果你的系统早就实现了资产和版本的严格绑定，那么这套能力其实早已扎根在你的系统之中，无非是还没有冠以“港口”之名而已。
```eof

文件已经生成好了，您现在可以在右侧编辑器中查看、修改或下载这个 Markdown 文件。如果还有什么需要调整的地方，随时告诉我！