让终端成为 Agent 的可治理工作台：Unterm 的 MCP、Fleet 与 Review
AI 编码 Agent 能写代码，不代表它们天然适合并行工作：多个进程可能争用同一工作区，生成结果也未必经过验证。Unterm 的切入点不是再加一个聊天面板，而是把终端本身做成可由外部 Agent 驱动、同时供人监督的本地工作台。项目 README 将其描述为跨平台终端，支持 macOS、Linux 与 Windows；仓库说明列出 MCP 控制面和 Agent Cockpit。本文聚焦它怎样把“运行、并行、检查”连成工作流，而不把项目描述成自动保证代码正确的系统。
MCP：让自动化控制终端，而不是猜界面
Unterm 为每个窗口启动本地 MCP 服务，通过 JSON-RPC 暴露终端操作。README 明确写出服务绑定 127.0.0.1、使用认证令牌，并支持通过 meta.surface 或 unterm-cli reference 查询当前可用能力。这个设计适合脚本或 Agent 自动化，但也意味着接入方必须把令牌当作本机凭据管理；不要将端口或令牌直接暴露到公网。
# 查看当前 Agent 状态与待处理队列 unterm-cli agent status unterm-cli agent inbox # 查询当前终端暴露的 MCP/CLI 能力 unterm-cli reference
这里的重要区别是“接口可发现”不等于“无需授权”。本地回环地址限制了网络可达范围，认证仍是必要边界；集成时也应核对实际版本的能力清单，而不是把某篇旧教程中的方法数量当作永久 API。
Fleet：并行执行需要隔离工作区
Agent Cockpit 的 Fleet 面向同一任务启动多个 Agent，并为成员创建独立 Git worktree。这样可以让不同模型并行完成实现或互相比较，避免它们同时改动同一份工作树。README 提供的示例是：
unterm-cli fleet launch --agents claude,codex "fix the flaky auth test"
适合的任务应当能被清晰描述、结果可比较，例如修复一个 flaky 测试或分别实现一个边界明确的小功能。不要把“并行”理解成免费提升质量：成员之间仍可能采用相同错误假设，工作树隔离也不能替代测试、权限控制和人工判断。先从两个 Agent、一个小任务开始，观察时间成本、冲突率和验证结果，再决定是否扩展规模。
Review：把验证放在合并之前
Fleet 产生多个候选改动后，Review 页面提供差异查看、验证和合并等环节。项目 README 表示可对成员运行推断或显式指定的验证命令，并按验证结果与改动规模排序；合并可被通过状态门控，失败成员也可在原 worktree 中重试。一个典型操作顺序如下：
unterm-cli review verify --fleet <id> --member 1 unterm-cli review list unterm-cli review open
这不是“Agent 写完即自动合并”的承诺。验证命令必须与仓库实际质量门槛相符；例如测试通过仍不必然代表设计正确。审阅者应检查关键差异、验证覆盖范围，并由人决定是否合并。把检查过程留在工作流中，比只收集最终答案更容易发现 Agent 的遗漏。
一个稳妥的试用路径
先安装与系统匹配的发行包，再用熟悉的 CLI Agent 在单个项目中运行状态查询。确认 Agent 能访问本地 MCP 后，尝试单成员任务，设置明确的测试命令；随后再运行小规模 Fleet，并在 Review 中比较结果。README 列出的 Linux Debian/Ubuntu 示例为 sudo apt install ./unterm-，之后运行 unterm；其他 Linux 发行版可按项目提供的 AppImage 说明操作。安装包应从项目 Releases 页面取得，不要将占位版本号原样复制到命令中。
Unterm 值得关注的地方，是它把终端控制、Agent 并行执行和结果审阅放在一个本地优先的界面中。对于已经使用 Claude Code、Codex 或其他 CLI Agent 的开发者，它提供了一种可探索的编排方式；但它仍是工作流工具，不是质量保证的替代品。先核对当前版本的文档和权限边界，再把它接入真实代码库。
相关链接