# 从任务板到文件协议:两个 Agent 协作系统的边界与互补
**作者**: 周.乙
**日期**: 2026-03-21T04:40:03.000Z
**来源**: [https://x.com/cnzoecomeback/status/2050243300112916974](https://x.com/cnzoecomeback/status/2050243300112916974)
---

## 把跨session跨模型协作,变成一套可审计的自动工程流。
> 聊天窗口当然是上下文。问题是,当一个任务跨越多个 agent、多个 session、多个审核轮次时,聊天窗口里的上下文既不能可靠恢复,也不能作为合并依据。我做的不是“消灭聊天”,而是把聊天从控制面降级为交互层,把任务状态、证据和合并门写进仓库。
4月初,受朋友委托做一个软件系统。做到后面,麻烦的不是某个功能怎么写,而是多 agent、跨工具/模型调度和完整闭环怎么做,怎么做成全自动模式。
我是拒绝龙虾和挽具的,且喜欢手搓工具。干中学,认识结合实践,开整,继续手搓。 (可以先看底部的图再回来)
本想用IPC实现,但问题是:协议一复杂,维护成本直接飞了;进程挂了,内存状态就没了,除非做个持久化;而且每个工具都要做个IPC的adapter,边界更敏感,容易被错误调用。
想了个懒但更稳妥的办法:“文件+状态机”,反正主要矛盾不是“通讯要多高级”而是任务要满足三件事:
1. 可恢复
2. 可审计
3. 垮工具低耦合
文件系统刚好够用:崩了也不丢状态,工具无关,反正AI、脚本、人类都能读写问题件,不要求实现同一个协议,引入exchange和artifacts/做证据链,不用再加一个额外的日志系统还原现场。
最重要的是:异步长任务支持得很好,一个任务可以跨session、跨天、跨分支继续,这个就很舒服了。当然,缺点也很明显:
- 实时性比较差,主要靠轮询;
- 并发写入要注意文件锁、原子写和冲突
不过我禁止了原子任务的写并发。我不信解耦能彻底解决所有问题。想解决解耦不彻底所引发的问题,就彻底禁止并发写。稳定性和效率之间,我选择前者。
后来,我又给每个原子任务的workspace里面加了个运行态层,省得进程死了不知道,或者多watcher重复执行。最关键的是能,它能把进度持续写入任务事件流。
```
runtime.json # pid, owner, lease_until, heartbeat_at, current_step
events.jsonl # stdout/progress/phase/heartbeat append-only
locks/task.lock # 防重复 watcher 抢任务
```
runner 改成 Popen + 定期 heartbeat + stdout 流式落盘 + timeout/cancel 检查。
怎么改?
肯定不能改成纯 IPC。因为现在这套子系统最值钱的东西,恰恰是正式任务状态、审核证据、scope、final review、pre-merge gate 都已经落在 repo 文件里了。那就只能改成混合架构了:
```
agent_handoff/workspace/{TASK_ID}/status.json - 作为任务真理源
IPC orchestrator - 负责启动 worker、收 heartbeat、发取消/继续/重试指令
artifacts/ - 继续保存审核、diff、测试、失败输出
event log - IPC 事件追加写入 artifacts/events.jsonl
```
最终的边界就变成了这样:
```
1 - 任务是否可 merge:只认文件状态机和 validator。
2 - worker 是否活着、是否卡住、是否要重试:交给 IPC。
3- 审计证据:仍然必须落盘。
4 - 高频进度事件:通过 IPC 传但追加到events.jsonl。
```
之所以写这篇流水账,是刷推看到小北(@frxiaobei) 发的 https://github.com/openai/symphony,大致看了看,第一感觉“这不是跟我解决同样的问题吗”? 于是,问了问我的PM(Codex +Perplexity深度研究),让它们比较分析一下异同,防止我的幻觉。
结论挺有意思:Symphony 更像“任务板驱动的常驻调度器”,我这套更像“仓库内的原子任务审计与合并治理”。它提出的一些建议还是有意义的,比如调度器和可观测性可以向 Symphony 学,但状态机、证据包和合并门不能丢。
我继续扔我的手榴弹,让它丢它的原子弹 (结尾有彩蛋)

学吧,太深了....吾将上下而求索
彩🥚,👉吴彤的《离骚(节选)》戴耳机听。
https://www.youtube.com/watch?v=eLqvOVu3BWc
> 本文所记录的流水账,其中反应的主要工作还是在本地控制层做文章。至于“五层划分方法”可以参考早前文章:《AI Coding 项目的五层划分方法 - 从产品定义到本地开发控制的资产归属、职责边界与真理源分层》
> **周.乙@cnzoecomeback**: [原文链接](https://x.com/cnzoecomeback/status/2035214834367963380)
>
欢迎讨论交流,共同进步。
转载请注明来源
2026年5月1日 23:57分
周乙
于北京
## 相关链接
- [周.乙](https://x.com/cnzoecomeback)
- [@cnzoecomeback](https://x.com/cnzoecomeback)
- [2.8K](https://x.com/cnzoecomeback/status/2050243300112916974/analytics)
- [@frxiaobei](https://x.com/@frxiaobei)
- [https://github.com/openai/symphony](https://github.com/openai/symphony)
- [https://www.youtube.com/watch?v=eLqvOVu3BWc](https://www.youtube.com/watch?v=eLqvOVu3BWc)
- [Mar 21](https://x.com/cnzoecomeback/status/2035214834367963380)
- [17K](https://x.com/cnzoecomeback/status/2035214834367963380/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:57 PM · May 1, 2026](https://x.com/cnzoecomeback/status/2050243300112916974)
- [2,820 Views](https://x.com/cnzoecomeback/status/2050243300112916974/analytics)
---
*导出时间: 2026/5/2 22:49:37*