Agent Coding 缺了什么
Coding agent 的工作单元全是一次对话，但真实的工程不是一轮对话的事。中间缺了一层让计划串起来的结构。
这些 coding agent 的工作单元，全是”一次对话”。
你打开终端，给 agent 一段指令，它读代码、改代码、跑测试，做完了这轮对话就结束。下次再开一轮，上下文从零开始。任务之间什么关系、哪些做完了哪些没做、上一轮 review 发现了什么——全靠你自己记，或者靠 agent 去读 git log 猜。
修个 bug、加个字段，一轮对话搞定，关掉就关掉了。
但真实的工程不是一轮对话的事。
一轮对话装不下的事
给一个项目加 OAuth 登录。拆开看：数据库 schema 变更、auth middleware、前端登录流程、token 刷新、已有接口的权限改造，可能还有文档。这些步骤有依赖，middleware 没写好前端就没法联调，schema 没迁移后端跑不起来。
你可以一个一个 prompt 去喂。但这时候你其实同时在做两件事：写代码，和在脑子里维护一张任务图。
agent 看不到这张图。它每次进来，只看到当前这条 prompt 和它能读到的代码。不知道这是更大计划的第三步，不知道第一步的 review 有人提了个点还没处理，不知道第五步依赖第二步的输出格式。
你变成了调度器。agent 是执行器，但调度全靠你。
中间缺了一层
agent 单次执行已经很强了。问题是没有一个结构去承载”计划”。
计划不是一段 prompt。是一张有依赖、有状态、有执行记录的图。
项目管理工具管的是人的跟踪，谁负责什么、deadline 几号。Agent 框架管的是 LLM 调用链，粒度太细。中间缺一层：把工程计划结构化，每个节点交给合适的 agent 执行，执行完能 review、能反馈、能接着走。
这个位置是空的。我做了 PlanWeave。
PlanWeave 做了什么
项目在 PlanWeave 里是一张图。节点是任务，每个任务挂着实现块、review 块、反馈块，block 之间有依赖、有状态。agent 领取一个 block 的时候，能看到自己在整张图里的位置，前置依赖完成了没有，上一轮 review 说了什么，项目级上下文是什么。
不同 block 路由给不同的 agent。实现交给 Codex，某些块交给 OpenCode，纯校验的步骤一个本地脚本就够。不是所有事都需要大模型。
Review 是内建的。review block 产出结构化结果，需要改的话反馈回到实现 block，agent 接着改。这个循环自动跑。
所有东西都是文件。plan、prompt、执行记录、report，全在本地工作区，git 可追踪，不依赖云服务。CLI 是主力，桌面端是 Electron 做的可视化画布，适合看全局，目前还在实验阶段。
还很早期
0.1.0。能用，但粗糙。
接下来想做的：让自动执行真的可靠，不是能跑通就行；多人协作的任务图板，计划这件事本来就该一起讨论；跨主机协调，让不同环境里的 agent 各自领任务、交产物。
我做这个不是因为觉得现有的 agent 不好。是因为觉得它们缺一个东西站在上面。
单次对话已经够强了。差的是让这些能力在一个跨对话的工程计划里串起来的结构。PlanWeave 补的就是这一层。