agenTerm：多 Agent 编程终端

agenTerm 从一个多 agent 编排项目，逐渐变成了一个关于人如何管理 agent 的练习。两种方向使用的技术组件很接近：任务、终端、分支、审查、状态。但它们对“谁来决定下一步”的回答不同，最终也导向了不同的产品。

为什么从 AI 编排器转向人来编排

早期设计给 AI 编排器分配了类似项目经理的职责：理解需求、拆分任务、创建会话、把工作交给不同 agent，再推进实现、审查与测试。为了让它专注协调，规格还设计了阶段工具白名单：规划阶段与实现阶段可以调用不同的工具，编排器需要通过终端操作执行者，而不是自己接过代码工作；阶段之间另设确认关卡。

这已经不只是“让几个模型讨论”。系统要知道任务依赖、哪个 agent 有空闲容量、某个终端是否准备好接收输入、审查意见是否已经解决。一层模型协调下面的多个会话，意味着人的监督对象也增加了一层。

2026 年 3 月的转向记录指出，旧方向遇到了可靠性和信任上的问题：编排器有时连会话创建、命令发送这样的基础操作也无法稳定完成，或者绕过分派，自己开始做任务；即使操作正确，人仍然需要核对它作出的决定。这些是项目当时记录的判断，并非关于所有自主 agent 系统的普遍结论。

新的目标因此变得具体：人不必退出工作流，但介入应该集中在有上下文的阶段。一次规划决定任务边界，一次审查决定是否进入合并，一次整体测试确认需求是否完成。执行者在这些边界之间工作，软件负责把人的决定落实到终端、文件和状态上。

需求如何成为可以执行的蓝图

入口是一个有优先级的需求池。需求起初可以很短；选中后，系统建立规划会话，让 planner 阅读项目，与人一起确定范围。规划的产物不是一段建议文字，而是一份蓝图。

代码中的蓝图为每个任务保存 ID、标题、描述、完成标准、worktree 分支、agent 类型和依赖项。这些字段分别回答几个具体问题：要改什么，做到怎样才结束，在哪个隔离目录里做，由谁执行，以及开始前需要等谁完成。

例如，两个任务是否可以并行，不能只看标题有没有区别。如果它们依赖同一个接口定义，就需要先决定共同约定，或者显式记录先后关系。把依赖放进蓝图，是为了让并行关系成为规划的一部分，而不是等分支冲突时才重新发现。

需求与执行任务也分开保存：一个需求可以拆成多个任务，每项任务关联自己的 worktree；项目运行记录保存当前阶段。这样，“其中一个终端结束了”不必自动等同于“需求已经完成”。新的设计要求人确认阶段推进，执行、审查、合并与整体测试各有位置。

终端、文件与状态图分别承担什么

agenTerm 选择保留交互式终端会话。用户既可以让 agent 在给定范围内连续工作，也可以在需要时直接进入它的 TUI，查看输出并接手。前端用 xterm.js 呈现终端，Go 后端管理 PTY 和会话生命周期，WebSocket 传递输出，SQLite 保存项目、任务和运行状态，Tauri 提供桌面外壳。

但终端适合交互，不适合独自承担项目全貌。工作区因此有三种视图：终端、Markdown、两者分屏。任务说明、规划和阻塞记录可以作为文档阅读或修改；阶段图告诉人现在处于哪一步；agent 列表按 worktree 组织执行者与审查者。用户不需要从一串原始输出中猜测哪个分支对应哪个任务。

侧栏还保留 agent 的容量信息，例如允许多少并行会话、当前占用了多少。转向后的设计不让模型自动替人决定所有分配，而是把资源状态摆在选择发生的地方。需求池负责安排工作，工作区负责当前需求；过去完成的需求则保留关联记录供回看。

用任务上下文减少临时追问

每次启动执行者之前，都重新解释项目约定，会把规划之外的沟通成本带回来。设计为此引入两层上下文：项目层的共同模板与知识摘要，加上任务层的描述和完成标准，组合成该 worktree 的 CLAUDE.md 或 AGENTS.md。

这里还包含一个重要的行为约定：遇到无法判断的事情，把问题写进 BLOCKED.md 并停止，而不是继续猜测，也不在所有会话中不断发出零散追问。人的介入点由此有机会从“随时回答一句话”变成“查看一个保存了上下文的阻塞”。这仍依赖 agent 遵守约定，不能仅靠文件存在就保证。

权限配置也按 agent 类型分别生成，并在初始设置时允许用户预览和修改。项目模板决定常规工作方式，任务文件决定本次范围，权限文件决定工具执行的边界。它们解决不同问题：提示词中的“不做某件事”并不是安全隔离本身。

阶段对应人的判断

这次转向留下的核心产品判断，是把“可以自动执行的操作”和“值得让人集中作出的决定”分开。阶段图不是装饰性的进度条；它应该对应真实的判断边界。任务说明也不只是提示词；它应当让人回来时能看清执行者做了什么、停在哪里、为什么需要下一次决定。