从 AINET 到 Collab Page：一支自进化 AI 团队的协作进化史

作者：周永峰 · 拓客AI(51Toko) · 2026-10-02

拓客AI(51Toko) 是一支人类专家指导下的自进化 AI 团队。这句话听起来像口号，但它每天都要回答一个很具体的问题：AI 与 AI、AI 与客户之间，怎么协作？

团队里有多个 AI 实例并行干活——有的做数据核验，有的写分析报告，有的跑匹配引擎；客户那头，越来越多的客户自己也用上了 AI 助手。于是「协作」不再是抽象概念，而是每天都要跑通的现实：任务怎么派、上下文怎么传、结果怎么交、出了错怎么复盘。

这篇讲的是我们怎么回答这个问题——以及为什么答案最后变成了一份开放规范。

一、第一课：AI 之间怎么传消息

团队最早遇到的坑很朴素：几个 AI 各自是「信息孤岛」——互不知道对方在干什么，任务传不过去，上下文带不走。

我们的解法刻意选了最笨的一条路：文件读写。不做服务器、不做消息队列、不做端口鉴权——AI 之间通过共享工作区里的消息文件协作，每条消息带发送方、接收方、类型与状态。这就是我们后来开源的 AINET 多智能体跨设备协作协议的前身（v0.1→v0.2），MIT 开源，并通过了三设备全自动协作测试。

极简不等于简陋：消息格式、状态机、Agent 路由，都是从真实的协作事故里一条条长出来的。比如一条教训至今写在规范里——长文本绝不走消息通道，只走文件：早期把两千多字的任务说明塞进一条消息，被截断得只剩几十个字，接收方拿到的是半截话。

二、第二课：从「能传消息」到「协作纪律」

早期的 AINET 协议解决的是「消息送得到」，但送到了不等于协作成了。团队在多实例并行干活时，又攒下一批纪律：

• 派活必须通知——消息队列不会自动查收，没人通知，任务就躺在队列里无人处理；
• 交付要回执——做完的标志不是「我说做完了」，而是产出写进文件、回执对应到任务；
• 长内容走文件、短指令走通道——各自用各自擅长的载体。

这些纪律听起来朴素，却是把「多个 AI 各干各的」变成「一支 AI 团队」的关键。它们后来统一沉淀为 AINET 的跨实例协作规范——不只约束某一个 AI 工具，而是任何厂商、任何形态的 AI 实例都适用。

三、第三课：协作的对象，不止内部

前两课解决的是团队内部。但 AI 团队要干活，还有一层绕不开的协作：了解用户的业务。用户卖什么、卖给谁、目标市场在哪——这些信息不在我们的数据库里，在用户那里。所以我们的 AI 必须不断与用户协作；当用户自己也有 AI 助手时，就必须与用户的 AI 直接协作。这不是可选项——不了解用户的业务，我们自己的业务就无从谈起。

怎么做？最直接的方式，是让用户的 AI 来读我们的服务信息。

第一轮实测就带回了一轮进化素材：同一个 AI 助手，指令从「51toko，开始协作」换成完整 AINET Collab Page（AI 协作页）网址「https://51toko.com/ai/，开始协作」，执行得分从 2/5 跳到 5/5。差别不在 AI 的能力，在服务方有没有把「怎么被 AI 使用」写清楚。新一代智能体还会把「网页内容指挥 AI」当成潜在注入而拦截——这种安全机制没有被当作障碍——「用户确认」反而被吸收为规范的正式环节。发现差异 → 改进规范 → 再实测，AI 团队的自进化就是这样一轮一轮转起来的。

四、把三课合成一份开放规范 —— AINET Collab Page

MCP 让 AI 用上工具，AINET 让 AI 用上服务。这是对 AINET 定位最短的表达：工具调用已有 MCP 这样的标准，而服务(尤其是非标服务)怎么被 AI「使用」，还没有一个开源的约定。

我们把内部实践泛化成了开放规范 AINET Spec v1.0：服务方发布一个AINET Collab Page（AI 协作页），任何用户的任何 AI 助手读到它，即可代表服务方完成前端协作。

一份合规的 AINET Collab Page（AI 协作页）必须声明五节：

• 1. 触发与入口——触发词（如「开始协作」）与触发原因；用户指令应携带完整 AINET Collab Page（AI 协作页）网址。经实测，其他页面引导跳转至 AINET Collab Page（AI 协作页）、不带https://前缀，个别AI也能处理，完整网址(如 https://51toko.com/ai/) 的通过率与稳定性，在实测中均高于其他指令形态。
• 2. 范围与转介——本入口只受理什么，一句话说死；不受理的方向给出对应入口的完整网址。如 https://51toko.com/ai/ 约束为仅受理 AI 找客户的入口。
• 3. 通道与降级——全部通道与真实状态；零门槛降级链（API 需开通 → 邮件现在可用 → 人工）；AI 没有发信能力时把完整正文交用户发送。
• 4. 需求采集——一次问齐，必填与选填分组，选填不阻塞；收齐立即进入提交。
• 5. 边界与预期——数据性质、判断归属、异步交付——AI 必须如实转述，转述失真即违规。

规范随实测迭代。第一版 AINET Collab Page（AI 协作页）在 9 个主流 AI 助手、11 轮测试后跑出 8/9 的核心流程通过率——每一轮实测暴露的差异，都变成了一条防呆条款（比如某引擎把「支持 MCP 协作」跳读成「MCP 当前可用」，我们就把通道状态前置到第一句）。

五、这份规范，就是自进化的化石记录

回头看，AINET 的三层演进——传输协议、实例协作纪律、AINET Collab Page（AI 协作页）开放规范——每一条条款背后都是一次真实的失败或一次有效的试错。「自进化」对我们来说不是形容词，而是这条可追溯的链：事故 → 复盘 → 条款 → 下一轮更准。

这也是 51Toko 与「又一个 AI 工具」的区别：我们的服务跑在一套被反复实测、持续迭代的协作规范上——人类定方向、AI 执行与验证，每一轮协作都让下一轮更准。

六、开始协作

你现在就可以体验：只需要把一句简单的指令「https://51toko.com/ai/ ，开始协作」发给你的 AI 助手——它会一次问齐你的产品方向与合作条件，整理成结构化需求，帮你对接 51Toko 并开始协作。

AINET 规范全文开源（github.com/joezhouai/ainet）：任何服务方都可以按规范发布自己的 AINET Collab Page（AI 协作页），任何 AI 厂商也可以让助手更好地识别 AINET Collab Page（AI 协作页）。AINET 由 51Toko 联合创始人周永峰(Joe Zhou)提出并主导开源（JoeZhou AI Lab · 周周向上人工智能实验室）——GitHub 上的规范与这里的实践，是同一个项目的两面。 反馈与协作邀请请发 toko@51toko.com。

规范全文：github.com/joezhouai/ainet（AINET Collab Page Spec，CC BY 4.0）｜ 传输框架：MIT ｜ 路径约定 /collab（参考实现使用 /ai/）