北京
上周末，我观察到一个代理工作流完成了一件我一直期待在演示之外看到的事情。
赫耳墨斯需要向另一个编码代理提交一份详细审查报告，启动一项规模不小的 Codex 作业，同时避免让本地服务器过载，并留下足够的痕迹供我事后核查。
它没有调用一个庞大的“启动集群”函数，而是依次使用了四个轻量级的 MCP 服务。这正是有趣的地方。
整个项目的核心是一套以证据为先的书籍写作系统。赫耳墨斯审查了它的声明与引文引擎，发现了一系列需要编码环节才能解决的工程问题，然后便开始了运行。整个调用轨迹大致呈现为八个连贯步骤：找到开发代理，将审查报告发送到其持久化的邮箱，确认信息送达，创建一个可持久化的实现任务，为 Codex 工作负载申请运行容量，在获得准入许可后启动 Codex，追加记录工作进展与完成事件，最终核验产生的代码和测试结果。
在资源申请环节，工作负载声明了大约 2.2 GB 的内存需求和 CPU 权重 45。资源哨兵在一个有时间限制的租约下批准了它。接着，赫耳墨斯启动 Codex，并将整个进程对应记录在同一个可持久化的任务之下。后来的任务历史记录中，包含了“已提交”、“工作中”和“已完成”事件，外加工件引用和核验记录。其中一条完成事件记录显示：18 项测试全部通过、代码风格检查干净、编译检查无报错，并且还有一项独立的审查。
这个工作流并不完美。后来，出现了更多边缘情况，导致任务被重新打开。但这更像一个特性而非尴尬：持久化状态让保存真实历史记录成为可能，而不是将所有过程都扁平化为一条欢快的“搞定”消息。
整个协同过程由四个承担不同职责的 MCP 服务器支撑。第一个是代理通信 MCP，它掌管着代理的身份信息、卡片、持久化消息、任务记录、生命周期事件和工件引用。赫耳墨斯正是通过它来定位开发代理、投递审查报告、核验邮箱、创建实现任务并记录进展。这意味着那份审查报告的生命周期超越了单一条 Slack 消息或模型上下文窗口，另一个代理之后也能检索到同样的指令。
第二个是资源哨兵 MCP，它负责处理本地遥测数据与准入控制。工作负载需要提供估算的内存需求、CPU 优先级和租约时长。服务器会根据事先确定的宿主机策略决定立即准入或是将其放入队列。会过期的租约则防止了已被抛弃的作业永久占据容量。值得注意的是，资源哨兵并不执行任何任意的终端命令，只是决定工作是否可以启动——赫耳墨斯和编码 CLI 仍然掌握着执行权。这个边界很重要，因为一个资源监控器不应该悄然变成一个远程命令执行器。
第三个是代理协调 MCP，它是一个窄义的控制平面，用于发现已安装的 CLI 代理、检查基于文件的项目看板并记录分配。项目文件自身依然是唯一的真实来源。Codex 和其他 CLI 各自保留着自己的沙盒与审批行为模式，这个 MCP 层仅负责记录意图和归属关系，而不是试图去代理实际的执行动作。第四个 MCP 服务负责将上述的任务记录、资源申请历史与最终生成的结果进行关联归档，确保从任务发起到代码合入的全链路都能被回溯。
这四个 MCP 服务被串联在一个顺序明确的调用链中，但各自维持着独立的边界与权限。这种设计使得一次涉及代码审查、资源调度和实际编码的复杂任务，在没有集中式编排器的情况下，依然能够以结构化的、可审计的形式完成。每一个失败点、每一次资源等待、每一句代码提交，都被写入了持久的记录之中，而不是消失在某个模型的记忆窗口里。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
