里小咸熟悉我的朋友都知道，我这两年一直在折腾 ibbot 这个项目。最早它的定位很简单：一个跑在本地的智能助手，你问它答，帮写文案、查资料、算点数据。说实话，单机版本撑了大半年没出什么大问题，真正让我动"联机能力全面升级"这个念头的，是我开始让它处理跨领域复杂任务的时候。比如"帮我规划一条跨省骑行路线，同时评估沿途天气、住宿费用和补给点分布"——这种任务在单机架构下几乎跑不通：上下文只有一个，工具调用是串行的，任何一个环节出错整条链就断。所以今年年初起，我对 ibbot 做了一次比较大的架构重构，核心思路就是标题里那句话：把它从单个 Agent 变成一组能够互相发现、互相通信、协同分工的 Agent 网络。这篇文章会把这次升级从架构设计、通信层落地到踩坑修复的完整过程写下来，给正在做 Agent 化改造的朋友当一份实践参考。
1. 单机版ibbot的瓶颈：为什么这次升级必须动"联机"这刀
1.1 旧架构的"一问一答"模型
ibbot 早期版本的逻辑非常简单，本质上就是一层套一层的函数调用。核心代码就算简化到极致，也是这么个套路：
python复制def handle_message(user_input, session_id):
history = load_history(session_id)
result = llm_generate(user_input, history)
save_history(session_id, user_input, result)
return result
一旦遇到需要工具的请求，就塞一个 function calling 的循环进去，让大模型决定调哪个工具、把工具结果再喂回模型，直到模型认为可以收尾。这种模型最大的特点是"串行"：一个输入进来，必须走完整个链路才能出去，所有中间状态都捏在当前这一个进程里。在任务简单、工具数量不超过五六个的时候，这样写其实完全没有问题。但工具数量上来之后，问题就以肉眼可见的速度冒出来了。
1.2 三个让我忍无可忍的痛点
第一个痛点是上下文孤岛。在旧架构里，会话历史跟着单个进程走，不同工具之间不共享"世界模型"。天气工具返回了"后天杭州有暴雨"，但这条信息不会自动传递给做行程规划的函数，除非我在代码里手动把结果拼进下一次 prompt。工具一旦多起来，这种手动拼接根本没法维护，漏掉一次就是一次错误的回答。
第二个痛点是工具调用碎片化。每个工具都是独立实现的，没有统一的接口规范。有的工具接收 JSON，有的接收纯文本；有的会自己重试，有的抛个异常就结束了。表面上它们都叫"工具"，实际上没有任何共同的语义层。我每新增一个工具，都要先写一堆适配代码，把这些五花八门的格式翻译成模型能理解的样子。
第三个痛点是无法横向扩展。单机架构下，所有计算都在一个进程里跑，并发一高就卡；更恼火的是，某个工具崩溃可能导致整个 bot 挂掉，因为没有任何隔离机制。想加一台机器分摊负载都做不到，状态全在本地。说白了，单机版 ibbot 就像一个人包圆所有活的杂货铺老板，能力有限，一生病就全店停业。
1.3 一个真实场景逼我下决心
真正让我放下"还能再补补"的侥幸心理的，是一个真实的使用场景。当时有一个朋友让 ibbot 帮忙规划"杭州到千岛湖的三天两夜自驾行程"，要求同时兼顾天气、路况、沿途充电桩和预算。旧架构在第一步就露怯了——模型确实把任务拆成了四路，但代码层面没有并行执行的能力，只能串行跑。跑到第三个工具的时候，前两个工具的结果已经混在同一个上下文里，模型自己都分不清哪个天气数据对应的是哪一天。最后输出的行程里，第二天安排了户外骑行，而天气数据明明显示第二天暴雨。
那次之后我做了个决定：与其继续在单机架构上缝缝补补，不如直接以"联机能力"为基础设施来重构整个系统。所谓"联机"，就是把多个 Agent 当成一群协作者，通过网络协议交换任务、共享上下文、协同决策。这不只是技术升级，更是产品定位的转变——从"一个聪明的小助手"变成"一群会分工的 Agent 团队"。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 多Agent协作架构拆解：编排者、执行者与记忆者如何分工
2.1 为什么是"Agent"而不是普通微服务
很多朋友听到这里会问：你说的事情，普通微服务也能做，为什么非要扯上 Agent？我的回答是：微服务解决的是"服务之间怎么互相调用"的问题，Agent 架构解决的是"每个节点怎么独立做决策"的问题。普通微服务的每个节点只是执行预定义的接口，而一个 Agent 节点自带模型推理能力和工具使用权，它可以自己决定该调用什么、该相信什么、该怎么响应。
举一个具体的例子。一个天气微服务，你传入城市和日期，它返回天气数据，仅此而已。但一个天气 Agent，你告诉它"明天杭州适合户外活动吗"，它能自己决定调哪家天气接口、要不要同时对比两个数据源、发现数据冲突时该信哪边，甚至能结合湿度数据给出"体感闷热，建议改室内"的结论。这种自治能力是普通微服务给不了的。所以我给 ibbot 定下的第一条原则就是：每个节点都是自治的 Agent，节点之间通过消息协议协作，而不是通过硬编码的 RPC 接口互相绑定。
2.2 Agent角色表：分工明确的六种角色
重构后的 ibbot 内部有六种 Agent 角色，我把它们的职责和典型配置整理成了表格：
| 角色 | 职责 | 数量配置 |
|---|---|---|
| 编排者（Orchestrator） | 接收用户请求，拆解任务，分派给下游，汇总结果 | 1~3 |
| 规划者（Planner） | 负责复杂任务的步骤拆解与执行顺序编排 | 1 |
| 执行者（Worker） | 具体干活，查天气、算预算、生成文本 | N（按需扩展） |
| 记忆者（Memory） | 管理长期记忆、会话状态、上下文版本 | 1~2 |
| 工具代理（Tool Proxy） | 封装外部 API，统一输入输出格式 | N |
| 护卫者（Guard） | 校验输出质量、敏感信息、结果一致性 | 1 |
这个分工参照了现实中项目团队的运作方式：编排者是项目经理，规划者是方案设计师，执行者是干活的工程师，记忆者做会议纪要，护卫者做最终审核。每个人只关心自己那一摊事，通过消息互通状态。这样设计还有一个额外好处——每个角色的代码可以独立部署、独立升级，不用整个系统一起发版。
2.3 注册与发现：Agent网络怎么知道彼此存在
Agent 之间要协作，首先得互相"知道"对方的存在。我在注册中心（Registry）里维护了一份 Agent 元数据，核心字段类似这样：
json复制{
"agent_id": "tool_agent_weather_01",
"agent_type": "tool",
"capabilities": ["weather.query", "weather.forecast", "air_quality.query"],
"endpoint": "agent://node-03:7801",
"status": "online",
"load": 0.4,
"queue_depth": 3,
"last_heartbeat": "2025-06-18T08:32:11Z"
}
每个 Agent 启动时向注册中心上报自己的能力和地址，之后每 5 秒发送一次心跳，注册中心根据心跳维护一份"当前谁活着、谁能干什么"的动态清单。编排者要派任务时，先向注册中心要一份能处理某类任务的在线 Agent 列表，再根据负载和健康度选一个目标。
这套机制带来一个很大的好处：新增能力时完全不用改编排者的代码。我新写一个股票 Agent，在注册中心声明 capabilities 为 ["stock.query", "stock.news"]，编排者下一次遇到相关任务时就会自动把它纳入候选。这也就是我坚持用 Agent 而不是硬编码工具列表的原因——系统是真的可以生长的，不是靠人肉改代码长出来的。
3. 联机通信层落地：协议对比、消息设计与会话同步
3.1 协议选型：为什么没选纯HTTP
Agent 之间要通信，第一个绕不开的问题是选什么协议。我把当时认真比过的几个方案列成了表：
| 方案 | 优点 | 缺点 |
|---|---|---|
| HTTP/REST | 简单、生态成熟、排查问题方便 | 单向请求-响应，服务端无法主动推送；短连接开销大 |
| WebSocket | 全双工、低延迟、适合实时双向通信 | 连接管理复杂，断线重连要自己处理 |
| 消息队列（RabbitMQ/MQTT） | 异步解耦、支持发布订阅、投递可靠 | 组件重，本地部署运维成本高 |
| Redis Streams | 轻量、性能好、支持流式消费 | 需要自己维护消费进度，客户端行为要仔细设计 |
最后我采用的是 WebSocket + Redis Streams 的混合方案。WebSocket 负责编排者和执行者之间的实时双向通信，因为编排者需要随时给执行者下发新指令，执行者也可能会主动请求上下文（比如"我这边缺昨天的天气数据"），用纯 HTTP 的请求-响应模型在这种场景下非常别扭。Redis Streams 则用来做异步任务队列——当某个执行者繁忙时，任务先进队列排队，由执行者按自己的节奏消费，这样削峰填谷很自然，也不会出现"一个慢任务堵住一整条链路"的问题。
3.2 消息结构设计
消息结构是联机通信的核心，我迭代了三版才定下来。第一版直接用自然语言字符串传，解析的时候一塌糊涂；第二版用了简单 JSON，但缺少路由字段，导致消息经常发错 Agent；最终版长这样：
json复制{
"protocol": "ibbot-agent-mesh",
"version": "2.1",
"msg_id": "msg_9a3f7c2e",
"trace_id": "trace_8b1d4e6f",
"msg_type": "task_assign",
"source": "orchestrator_main",
"target": "tool_agent_weather_01",
"session_id": "sess_6f2a9c",
"created_at": "2025-06-18T08:30:00Z",
"expire_at": "2025-06-18T08:30:30Z",
"priority": 5,
"payload": {
"task": "weather.query",
"arguments": {"city": "杭州", "date": "2025-06-20"},
"timeout_ms": 30000,
"retry_count": 0
}
}
msg_id 是全局唯一标识，用来做幂等和去重；trace_id 是链路追踪 ID，排查问题时所有 Agent 的日志都带上这个字段，就能完整还原一条调用链；expire_at 是任务过期时间，防止任务无限期悬挂在队列里。这套消息结构后来成为我排查故障的利器——正是有了 trace_id，后面那几个死循环和悬垂问题才得以快速定位。
3.3 会话同步：多Agent怎么共享同一个上下文
单机版里上下文只有一个，重构之后多个 Agent 同时处理一个会话，怎么保证它们看到的是同一份上下文？我最初的想法是"每条消息都带上完整上下文"，结果发现消息体越来越大，几个回合之后就把网络带宽吃满了，完全不现实。
后来采用的方案是：上下文统一存在 Redis 里，消息里只携带 session_id 和版本号。具体执行逻辑是：
- 编排者在一轮任务开始时，给当前会话分配版本号，比如 v23。
- 每个执行者收到任务后，从 Redis 读取 session_id + v23 的上下文快照。
- 执行者完成任务后，把结果写回 Redis，并将版本号递增到 v24。
- 下一个执行者必须基于 v24 决策，不允许回读旧版本。
这相当于给上下文加了一个乐观锁。任何 Agent 如果发现自己拿着一个过期版本在做决策，就主动拒绝执行并请求最新版本。这个机制是后面解决"上下文漂移"问题的核心，具体细节在第 4 节展开。
3.4 心跳、超时与重试的阶梯策略
联机系统最怕的事情就是"节点死了但没人知道"。我在每个 Agent 里放了一个心跳线程，每 5 秒向注册中心上报存活状态，内容包括当前负载、队列深度、最近一次任务完成时间。注册中心如果连续 3 次没收到某个 Agent 的心跳，就把它标记为 offline，并从任务候选列表里剔除。
超时和重试方面，我制定了一套阶梯策略：普通任务默认 30 秒超时；超时后不立即重试，先把任务放回队列，等 10 秒再派给同一个 Agent——它可能只是临时卡顿；如果第二次还是超时，就换一个 Agent 执行，并把任务的 retry_count 标记为 2；如果连续三次重试都失败，任务进入"待人工确认"状态，不再自动下发。这套策略在后面救了不少场，但也带来过麻烦，这一点后面会讲到。
4. 升级实战中踩过的三个大坑：漂移、死循环与任务悬垂
架构设计得再漂亮，真正联调起来问题还是一堆。这一节我把升级过程中踩得最深、最值得写出来的三个坑完整讲一遍，每个都包含事发现象、排查过程、根因和修复方案。
4.1 上下文漂移：两个Agent对同一件事的理解分道扬镳
第一个坑出现在联机系统上线后的第二个星期。现象是：用户让 ibbot 对比"杭州和上海各三天两夜的旅行方案"，行程 Agent 给出的结果里，杭州段的预算和上海段的预算完全对不上——杭州段按 3000 元算，上海段按 8000 元算，可用户从头到尾只说了一句"预算不要太高"。
排查时我打开了 trace_id 日志，追踪这条会话里每个 Agent 实际读到的上下文版本。日志还原出来的片段是这样的：
code复制[08:30:01.001] trace_8b1d4e6f | orch → tool_agent_weather | task_assign | v23
[08:30:02.887] trace_8b1d4e6f | tool_agent_weather | context_read | v23 | ok
[08:30:05.224] trace_8b1d4e6f | tool_agent_budget | context_read | v24 | ok
问题一下就清楚了：杭州 Agent 读的是 v23 的上下文，里面确实有用户最初的完整需求；但上海 Agent 处理时，另一个并发的任务抢先写入了 v24，而且这个 v24 被一份不相关的工具结果"污染"了——那份结果往上下文里追加了一段"用户预算敏感度分析"，把"不要太高"错误解读成了"可以接受 8000 元以内"。
这个问题的本质是：并发场景下多个 Agent 同时向同一份上下文写入增量信息，后写入的覆盖先写入的，而且没有任何冲突检测。修复分三层落地：
第一层是版本锁，也就是 3.3 节说的乐观锁机制。任何 Agent 写入前必须声明自己基于哪个版本，写入时如果当前版本号已不匹配，就拒绝写入并强制重新读取。
第二层是语义隔离。把上下文按领域拆成子空间，比如 context:weather:杭州、context:budget:上海，每个 Agent 只读写自己负责的子空间，互不干扰。
第三层是写入审计。所有上下文写入操作都记录一条审计日志：谁写的、基于哪个版本、改了哪些字段。有了这套日志，再发生类似问题，我可以在五分钟内还原完整事发过程。
修复之后，"两个 Agent 意见不一致"的问题基本绝迹。我也建议任何做多 Agent 系统的朋友，上下文版本管理一定要从第一天就做，否则后面迁移成本高到你不想面对。
4.2 调用死循环：Agent之间互相"甩锅"
第二个坑更隐蔽。某天晚上我收到监控告警，ibbot 所在机器的 CPU 占用率飙到 95% 以上，而且持续了十几分钟。我登录上去一看，消息队列里有几十万条消息在疯狂流转，仔细一查，大部分来自同一个 trace_id。
用 trace_id 追下去，还原出的调用链是这样的：编排者给工具 Agent A 派了一个"查询天气"的任务；A 调用外部天气接口，接口超时；A 的异常处理逻辑是"把错误上报给编排者，请求重新派发"；编排者收到错误后，按照重试策略把同一个任务又派回给 A；A 再次超时，再次上报……循环往复，消息量指数级膨胀。
本质上，这是"错误处理逻辑踩了重试逻辑的坑"。A 的异常上报是自动的，编排者的重派也是自动的，两边都不认为自己在犯错，结果形成一个正反馈死循环。此外还有一个类似情况：Agent A 调用 Agent B，B 决定向 A 请求补充信息，A 又向 B 请求确认——两个 Agent 互相等待，谁也不往下走，这本质上也是一种死循环，只是表现形式不同。
修复方案有三条，全部落地：
- 调用深度限制。每条任务链最多允许 5 跳（Agent 之间消息传递的次数）。超过 5 跳，编排者直接判定失败，不再向下派发。这是最硬性的保护，没有例外。
- 环路检测。每个 Agent 处理消息时，把 trace_id 和当前 agent_id 的组合放入本地缓存。如果同一个 trace_id 在 30 秒内重入同一个 Agent 超过 3 次，该 Agent 拒绝处理并向上返回一个 "loop_detected" 错误。
- 错误分类。把 Agent 的错误分成"可重试"（如上游接口超时、网络闪断）和"不可重试"（如参数错误、数据结构不匹配）。只有可重试错误才触发编排者自动重派，不可重试错误直接进入人工处理队列。
这个坑给我的教训很深：多 Agent 系统的故障放大器恰恰是"自动化错误处理"。每一次自动重试都可能放大故障，所以重试必须带边界、带熔断、带人工兜底，否则系统会在你睡觉的时候把自己跑死。
4.3 任务悬垂：核心Agent突然挂了，任务卡死
第三个坑是任务悬垂。有一次用户反馈：某个查询任务跑了 20 分钟都没有结果。我查了消息队列，发现任务的 expire_at 早就过了，但任务既没有被标记为失败，也没有被重新派发——它就那样悬在队列里，不执行、不返回、不超时。
根因是：执行这个任务的那个 Agent 进程在任务中途因为内存溢出崩了。问题在于，进程崩溃前已经把任务从队列里取走，而"取走"和"任务完成"之间没有任何锁或租约机制。换句话说，消息队列认为任务处于"处理中"状态，但处理者已经死了。注册中心虽然通过心跳检测在 15 秒后发现了 Agent 掉线，但没有哪个组件主动去检查"这个 Agent 手里还有哪些未完成的任务"。
解决方案是租约机制：编排者派发任务时附带一个租约期限（比如 60 秒）；执行者拿到任务后必须周期性续租；一旦租约过期且没有续租，编排者判定该任务为"孤儿"，自动重新派发给另一个健康 Agent。为了规避重复执行，每个任务保留 msg_id，新的执行者拿到任务后会先做幂等检查——如果发现同一个 msg_id 已经有部分结果写入，就基于已有结果继续，而不是从零开始。
租约机制上线后，任务悬垂的问题彻底消失。事后复盘我意识到：多 Agent 系统里，任务状态不能只靠"队列 + 进程是否存活"来推断，必须有一个显式的租约和孤儿检测机制。这跟分布式系统里的分布式锁是同一个思想，不提前做好，迟早出事。
5. 任务拆解与结果聚合：把"联机"变成真正的团队协作
通信层解决的是"Agent 之间怎么说话"的问题，但真正让联机产生价值的，是"怎么把一个复杂任务拆成多个子任务并行协作，再把结果拼成完整答案"。这一节讲我在实践中沉淀下来的拆解、路由和聚合方法论。
5.1 三种任务拆解模式
我在 ibbot 里实现了三种拆解模式，由规划者按场景选用：
- 瀑布式（Waterfall）：任务必须按顺序执行，后一步依赖前一步的结果。比如"先查昨天的天气，再根据天气判断今天的穿衣建议"，第二步必须等第一步的返回值。
- 扇出式（Fan-out）：一个任务拆成多个互不依赖的子任务，并行执行。旅行规划里，天气、住宿、路况、预算这四路可以同时查，最后再汇总。
- 管线式（Pipeline）：前两种的复合形态，先并行拉数据，再串行做分析，再并行做校验。
规划者判断该用哪种模式，主要看两个依据：一是子任务之间有没有数据依赖，有依赖就瀑布，没依赖就扇出；二是子任务的可并行度，涉及外部 API 的优先并行，因为 IO 等待时间占比高，串行跑是纯浪费。
5.2 路由策略：任务怎么找到对的Agent
任务拆完以后，每个子任务要路由到具体的 Agent。我用了两层策略叠加。
第一层是规则路由。任务的 task 字段与 Agent 的 capabilities 做精确匹配，比如 task 是 "weather.query"，直接匹配到声明过该能力的 Agent。这层策略快、确定性强，适合任务类型明确的场景，占比大概七成。
第二层是语义路由。当任务类型不明确（比如用户说"帮我看看明天适不适合爬山"），先用规划模块把意图转化成候选能力列表——可能同时涉及 weather.query、trail.open、equipment.recommend——再通过语义相似度打分选择最合适的 Agent。语义路由的召回率高，但偶尔会选错，所以最后还有护卫者把关，检查输出是否答非所问。
5.3 结果聚合：多个答案怎么选
扇出式任务最难处理的是汇总环节。多个 Agent 各自返回结果后，怎么取舍？我实现了三种策略：
- 简单优选：多个结果都合法时，选第一个通过校验的，适合"查询天气"这种单一结论的任务。
- 投票共识：对事实性问题（比如"明天到底限不限行"），让 2~3 个信息源各自出结果，取一致答案；不一致时标记为"待确认"，不让模型强行编一个。
- 优先级合并：按规则决定谁的结果优先，比如安全相关结果（交通管制、极端天气）永远优先于便利性结果，成本相关结果在用户强调预算时优先。
这三种策略不互斥，可以在管线式的不同阶段自由组合。实际跑下来，这个取舍逻辑基本稳定，很少出现两个 Agent 的结果都合法但互相矛盾、系统不知道听谁的尴尬局面。
5.4 一个完整的执行流程示例
把旅行规划这个场景完整走一遍，大家感受一下联机协作的实际效果：
- 用户发来请求，编排者接收，规划模块拆出 4 个子任务：weather.query、hotel.search、traffic.query、budget.estimate。
- 4 个子任务互相没有依赖，走扇出式，并行派发给 4 个不同的工具 Agent。
- 4 个 Agent 各自从 Redis 读取 v23 上下文，处理后把结果写回，版本号递增到 v24。
- 编排者收到 4 份结果，先做合法性校验（格式、字段、时间戳），再传给规划 Agent。
- 规划 Agent 基于 v24 上下文做综合分析和行程编排，输出一份完整方案。
- 护卫者 Agent 检查方案中的敏感信息、预算数字一致性、时间冲突，发现问题就打回重做，没问题则输出给用户。
实际跑下来，这类任务从提交到返回完整方案平均耗时 12~18 秒。对比单机版串行跑同样的流程需要 3 分钟以上、而且经常跑偏，这个提速是非常明显的。更关键的是，联机架构下任意一个 Agent 崩溃，其他 Agent 不受影响，系统不会整体瘫痪——这是单机版无论如何都做不到的。
6. Web4视角下ibbot的定位：从回答问题到替用户办事
6.1 Web4到底是什么意思
"Web4"这个词在行业里还没有一个权威的统一定义，但大致共识是：它是继 Web3（以去中心化和数据所有权为核心）之后的新阶段，核心特征是由 AI Agent 作为用户与互联网之间的中介。行业里也把 Web4 叫做"共生网络"（symbiotic web），意思是这个阶段人们不再直接"浏览"网页，而是委托 Agent 去浏览、筛选、比较、下单、跟踪，Agent 之间再互相协同完成跨系统的复杂任务。
我把四代 Web 的差异梳理成一张表：
| 阶段 | 核心特征 | 用户角色 |
|---|---|---|
| Web1 | 只读静态页面 | 信息消费者 |
| Web2 | 读+写，平台化，用户生成内容 | 内容生产者 |
| Web3 | 去中心化，数据所有权，数字资产 | 资产持有者 |
| Web4 | AI Agent 中介，人机协作，任务自动化 | 任务委托者 |
在 Web4 的图景里，单个网页不再只是"给人看的"，同时也是"给 Agent 解析的数据源"；普通服务不需要在每个设备上都做一套界面，只要为 Agent 暴露一个可编程接口，用户就能通过自然语言让 Agent 完成操作。这跟我给 ibbot 做的联机升级在方向上完全一致：让 Agent 不再是你问我答的对话机器人，而是替你跑腿办事的"数字代理人"。
6.2 ibbot在这次升级里的突破点
这次升级对 ibbot 来说，真正的突破不在于多了一个功能点，而在于它完成了三层转变。
第一层，从"单机"到"联机"。ibbot 不再是一个进程里跑一个模型循环，而是变成了一组可以分布式部署、互相协作的 Agent 集群。单点故障有了冗余，负载可以横向扩展，整体可用性明显提升。
第二层，从"回答问题"到"执行任务"。以前用户问"上海明天天气怎么样"，它回答一段文本；现在它可以从多个数据源拉取数据并做交叉校验，结合行程安排给出"明天上海有雨，建议把外滩行程移到后天"这类主动建议。回答问题的 Bot 只是 Web4 的敲门砖，执行任务的 Agent 才是真正的价值所在。
第三层，从"被调用的工具"到"自治的协作方"。ibbot 的能力以 Agent 为单位对外暴露，其他系统可以像调用一位同事一样调用 ibbot 里的某个 Agent，而不是硬编码集成。这让它从"一个产品"变成了"一个可以嵌入更大系统的协作节点"。
6.3 实话实说：哪些已经做到，哪些还差得远
Web4 的愿景很宏大，但我得说实话：ibbot 的这次升级只是往那个方向走了一小步。已经做到的是 Agent 之间的通信协议、任务编排、上下文同步和基础自治决策；还没做到的是跨机构、跨系统的 Agent 间信任和结算机制，以及标准化的 Agent 间互操作协议。目前所有 Agent 都还跑在我自己的集群里，它们之间的协作属于"内网联机"；要真正实现"公网联机"，让不同机构部署的 Agent 可以安全地互相调用、互相付费，还需要行业层面的标准和信任基础设施。
所以我个人把当前这个版本定位成"Web4 的预演"——技术上先把 Agent 联机的内功练好，等外部标准成熟的时候，ibbot 可以很快接进去，而不是从零开始补课。
最后说一点个人体会。这次重构我最大的收获不是把 ibbot 跑得更快更稳，而是想明白了一件事：在 Agent 时代，单机能力再强也有天花板，真正稀缺的是让不同 Agent 在保持自治的同时还能高效协作的那套"联机"协议。Web4 会不会完全按现在这个剧本走，没人能打包票，但提前把 Agent 联机的基础设施做扎实，无论未来怎么演化，这一步都不会白走。