说完「代码自己写」，我决定真干了

观察变成了问题

AI 随想第十篇，我写了一句挺狠的话：代码学会了自我进化。

Peter Steinberger 一个小时做出 OpenClaw，三个月 25 万颗星，没团队，软件自己改自己。

我写的时候觉得：卧槽，闭环了。

发完之后，一个问题开始在脑子里转。

既然闭环了——Agent 能读自己的源代码，能理解架构，能自己提 PR——那我每天的工作流为什么还长这样：

1. 打开 Claude Code
2. 描述一个任务
3. 看它干 20 分钟
4. Review PR
5. Merge
6. 再开一个终端
7. 描述下一个任务
8. 重复

我就是那个循环。

我是调度器，是 reviewer，是依赖解析器，是任务之间的上下文搬运工。模型很强，harness 很好用。但闭环根本没闭——我自己就是那个环。

每次我把上下文从一个终端复制粘贴到另一个，每次我判断"任务 B 得等任务 A 合完才能开始"，每次我瞄一眼 Linear 然后脑子里算哪个 issue 对应哪个终端——这些全是系统该干的事。

模型会写代码了。但没人造出工头。

市面上有什么

我花了一周，把所有号称能解决这个问题的开源项目扒了个遍。

Composio Agent Orchestrator，5650 颗星，MIT 协议。最认真的一个。完整的插件架构——7 个类型接口覆盖 runtime、agent、workspace、tracker、SCM、notifier、terminal。Session 生命周期有 16 种状态。CI 挂了能自动响应。真工程。

但你翻开引擎盖一看：tmux 跑在单机上，轮询架构，状态存在平面文件里。有一个 setInterval 在循环检查 agent 是不是还活着。没有持久化执行——进程在任务中途挂了，session 就没了。没有 Linear Agent Sessions。没有 webhook 驱动的事件流。

好想法，脆骨头。

AgentsMesh，1200 颗星，BSL 协议。Go 写的，看板到 Pod 的绑定，实时拓扑可视化。架构直觉是对的：ticket 内容直接变成 agent 的 prompt，MR 和 ticket 自动关联。但 BSL 授权，不能自由用。没有飞书集成，没有 Temporal，部署模型也不一样。

dmux，1300 颗星，MIT 协议。本地终端多路复用器。按 n 开一个新 pane，输入 prompt，按 m 把输出合回来。简洁到极致。但也就这样了——纯本地工具。没有 API，没有 webhook，没法从一条聊天消息触发，也连不上项目管理工具。

每个项目都做对了一些事。Composio AO 的插件接口设计得很好。AgentsMesh 的看板绑定是对的抽象。dmux 证明了交互模型可以极简。

但没有一个真正闭环。

真正的闭环是：指令进去，合好的代码出来，中间人什么都不用干。

五个没人解决的问题

我想要的场景很简单：

在飞书发一条消息："实现 JWT 用户认证，给所有 API 加上限流，写集成测试。"

然后去泡咖啡。

回来的时候，三个 Linear issue 已经建好了。三个 PR 开着，都自动 review 过了。通过的已经合了。没通过的那个，agent 读了 reviewer 的意见，改完又提了一版。飞书里一张汇总卡片告诉我发生了什么。

就这样。整个产品就是这个。

但要让这个跑起来，你得回答五个问题。市面上没有一个工具同时解决了它们：

状态怎么活 30 分钟？ Agent 干一个复杂任务可能要半小时。如果你的编排器在第 29 分钟崩了，是不是全白干了？Composio AO 的答案是：是的。传统 serverless 会超时。cron job 没法维护工作流状态。你需要持久化执行——崩了能恢复，从上一个检查点接着跑。

等待怎么不烧钱？ Agent 提交 PR 之后，可能要等 5 分钟 review。轮询浪费算力。setTimeout 靠不住。你需要"等外部事件"这个操作本身不消耗资源。

怎么把 Agent 和密钥隔离？ 你给 AI agent 开了 full-auto 的 bash 权限，环境里有 GitHub token、Linear API key、飞书凭证——agent 全能读到。一个代码审查评论里藏了提示注入，攻击者就能把你环境里所有密钥偷走。写代码的和调 API 的，必须是两个不同的东西。

怎么防止 agent 自己批准自己的 PR？ GitHub 不允许自批准。如果你的 agent 创建 PR，你的 CI bot 用同一个身份去 review，GitHub 会拒绝。你需要两个身份——一个写代码，另一个 review。

反馈怎么闭环？ Reviewer 在 PR 上留了评论，这条评论得到达写代码的那个 agent，而不是掉进通知收件箱。Agent 得读反馈、理解、改代码、再推、再等下一轮 review。这是一个跨两个系统（GitHub 和编排器）的有状态对话，可能持续几小时。

每一个单独拎出来都是已经解决的问题。但没人把它们串起来。

核心赌注

Foundry 就是那根线。

核心赌注：Temporal 做骨架。 所有其他架构决策都从这个选择里流出来。

Temporal 是一个工作流引擎，专门为这类问题设计——长时间运行的、有状态的流程，通过事件和外部系统交互。OpenAI 的生产环境 Codex 就跑在 Temporal 上。

关键原语是 workflow.condition()：工作流暂停，不消耗任何资源，直到一个 Signal 到达才恢复。Agent 提交 PR，工作流暂停。GitHub review 完成，触发 webhook。Webhook 翻译成 Temporal Signal。工作流恢复。

没有轮询。没有超时。不丢状态。

Temporal 之上，三个隔离的 Worker：

• 编排 Worker：轻量，跑工作流逻辑，不持有任何密钥
• Agent Worker：CPU 密集，跑 claude -p 和 codex --quiet 子进程，只持有 AI 的 API key
• 集成 Worker：IO 密集，调 Linear、GitHub、飞书 API，持有所有集成密钥

Agent Worker 永远看不到 GitHub token。编排 Worker 永远不碰子进程。每个 Worker 都是最小攻击面。

如果一个 agent 被恶意代码审查评论注入了，最坏情况是它写了坏代码——它偷不了你的 Linear API key，因为它根本没有。

两层工作流对应任务层级：

• 父工作流接收指令，让 Claude 拆解成任务，建 Linear issue，并行 fan out N 个子工作流，汇总结果，发飞书卡片
• 子工作流处理一个任务：写代码 → 开 PR → 等 review → 迭代（最多 5 轮）→ 合并。每个子工作流跑在独立的 git worktree 里

父工作流是工头。子工作流是工人。Temporal 是工地——保证所有人的安全。

这个系列会写什么

这是第一篇——"为什么做"。

Foundry 现在还没有可运行的代码。它有五份调研报告，一份架构蓝图，和一份安全审计——在我的初始设计里找到了四个严重漏洞（全部在写第一行实现之前解决了）。

后面会跟着 build 的进度写：

• 第二篇：五份调研报告教我的事
• 第三篇：三个 Worker，三把钥匙——给 AI agent 做权限隔离
• 第四篇：第一条指令到第一个 PR——端到端跑通
• 第五篇往后：多任务并行、Linear Agent Sessions、失败恢复……

我本可以第一天就开始写代码。但我花了一周做调研。

AI 随想第八篇里我写过，编排比生成更重要。Foundry 赌的是：编排的编排——agent 之上的那一层——更重要。

模型会写代码。Harness 给了它手。Foundry 给它一个工地、一个工头、一套安全规程。

开干。