Brigade：给多 agent 编码流程留收据的本地控制台
现在很多团队已经不只用一个 coding agent 了。Claude Code、Codex、Cursor、OpenCode、VS Code、Grok CLI 各有自己的 MCP 配置、指令文件、记忆方式和插件形状。单独用时问题不大；一旦想让它们共享同一套工具和上下文，配置就会变成一堆手工同步的文本文件。
更麻烦的是，agent 自己说“这次做得不错”没有什么价值。真正值得保留的，是它运行过什么命令、退出码是什么、改了哪些文件、某条 skill 或记忆卡是否真的帮到了下一次工作。没有这些收据，所谓自我改进很容易变成提示词堆叠。
今天想记下的 escoffier-labs/brigade，就是围绕这个问题做的本地 CLI 控制台。README 里的定位很明确：Brigade 不是托管记忆服务，也不是一个 MCP server，而是在本地仓库里维护 .brigade/ 状态、AGENTS.md、安全规则、handoff、MCP catalog、工具同步计划和验证收据。它强调 dry-run diff、plain files、no daemon、no lock-in，目标是让多 agent 编码流程有一套可审计的本地工作台。
按 GitHub repository API、README、release API、tags API、commits API、languages API 和 LICENSE 在 2026-07-13 能核验的公开信息，escoffier-labs/brigade 当前有 59 stars、4 forks。仓库主语言是 Python，许可证是 MIT。仓库创建于 2026-05-13 21:55:58 UTC，最近 push 是 2026-07-12 14:59:31 UTC。默认分支 main 当前最新提交是 e2547edd，提交时间 2026-07-12 14:51:51 UTC。GitHub Releases 页的 latest release 是 v0.21.1，发布时间为 2026-07-09 19:00:29 UTC；Tags 页当前最新 tag 也是 v0.21.1。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | escoffier-labs/brigade |
| 定位 | 面向多 agent coding workflow 的本地控制台与收据系统 |
| Stars | 59 |
| Forks | 4 |
| 主语言 | Python |
| 许可证 | MIT |
| 仓库创建时间 | 2026-05-13 21:55:58 UTC |
| 最近 push | 2026-07-12 14:59:31 UTC |
| 最新 main 提交 | e2547edd，2026-07-12 14:51:51 UTC |
| Latest GitHub release | v0.21.1 |
| 核心入口 | pipx install brigade-cli、brigade operator quickstart、brigade operator doctor |
| 关键词 | MCP catalog、handoff、memory、file receipts、dry-run diff、local-first |
痛点不是没有 agent，而是每个 agent 都有自己的抽屉
Brigade 最直接的入口是：
pipx install brigade-cli
brigade operator quickstart --target ./my-repo --harnesses codex
brigade operator doctor --target ./my-repo --profile local-operatorREADME 说 quickstart 会在目标仓库里接入 memory、handoff、本地 MCP catalog、work loop 和 guardrails。默认 footprint 不大：AGENTS.md、SAFETY_RULES.md、handoff template，以及 .brigade/ 状态。它也强调先 dry-run，再写入。
这类工具有意思的地方，不在于“又多一个 agent wrapper”，而在于它把 agent 生态里最烦人的部分当成一等问题：每个 harness 都有自己的配置文件。Claude Code 读 .mcp.json，Cursor 读 .cursor/mcp.json，Codex CLI 是 .codex/config.toml，OpenCode 又是另一套形状。Brigade 的思路是保留一份 .brigade/mcp.json catalog，再把它投影到各工具的原生配置里。
这听上去不酷，但很实用。很多团队的 AI 工具管理并不是输在模型能力，而是输在“这个 MCP server 只在某个客户端里配置了”“某个 agent 的规则文件忘了更新”“上一轮 handoff 留在另一个工具的私有角落”。Brigade 想把这些角落摊成一组本地文件。
收据比自评更重要
README 里最值得注意的是 “prove” 和 “improve” 两层。Brigade 可以用 verify run --capture 记录命令、真实退出码和变更，然后用 outcome ledger 统计某个 skill 或 card 是否真的帮到了工作。它的说法很克制：skills 和 cards 只根据真实 exit code 升级或回滚，不根据模型自评分。
这比普通的 agent memory 更硬一点。memory 很容易变成“把上次对话摘要塞进去”，但摘要未必有用，甚至可能污染下一次上下文。Brigade 试图把可学习对象和验证信号连起来：某条 skill 帮助了通过测试的 run，就积累正信号；如果验证失败，就不能靠模型一句“我觉得有帮助”蒙混过去。
latest release v0.21.1 也在这个方向上继续加固。release note 提到 memory-doctor、search station、tokens station、evidence station、pantry station、Hermes/Grok MCP adapter，以及 outcome reconcile / fork 的 fingerprint-aware promotion ratchet。简单说，Brigade 不只在收集收据，也在避免一条被改写过的 skill 继续吃旧文本留下的功劳。
我会把这个视为 Brigade 的核心特色：它不是帮 agent “更聪明”，而是让 agent 工作之后留下能被下一轮使用、检查和回滚的证据。
MCP 同步是最容易理解的切入点
如果只想试一个功能，MCP catalog 可能是最容易落地的。README 给的例子是：
brigade mcp init
brigade mcp add --name github --command npx \
--args "-y @modelcontextprotocol/server-github" \
--env GITHUB_AUTH_ENV=ref:BRIGADE_GITHUB_AUTH_ENV
brigade mcp sync
brigade mcp sync --writedry-run 会展示每个工具将要创建或更新的 server 条目，--write 才真正合并。README 明确写了 Claude Code、Cursor、Codex CLI、Grok CLI、VS Code、OpenCode、Antigravity 等目标，并且强调 secrets 用变量引用，不直接内联。
这部分很适合已经在多个 agent 客户端之间切换的人。你不一定要立刻采用 Brigade 的 memory 和 outcome 体系，也可以先把它当成“多 harness MCP 配置同步器”。如果这个小入口能省掉手工复制配置，后续再看 handoff、receipt 和 station。
它的世界观比较完整，也比较有主张
Brigade README 里有一组 “stations”：GraphTrail、MiseLedger、Agent Pantry、Content Guard、Skillet、Token Glace。核心仓库是 hub，外部 sidecar 按需安装。比如 GraphTrail 负责 code graph，MiseLedger 负责 evidence ledger，Agent Pantry 处理跨机器会话/secret 同步，Content Guard 做 secrets 和 PII scan。
这说明它不是一个很薄的脚本，而是在搭一套多 agent 操作系统式的工作流。好处是边界想得比较全：共享、记忆、证明、改进、安全扫描、token 压缩都有位置。坏处也在这里：如果你只想要一个极简工具，Brigade 的概念密度会偏高。
我更建议把它当成一个可拆的工具箱看。第一步可以只试 operator quickstart --dry-run 或 mcp sync；第二步再看 handoff 和 memory；最后才考虑 outcome reconcile 这种更自动化的晋级/回滚机制。不要一开始就把整个世界观搬进生产仓库。
适合什么场景
第一类场景，是你同时使用多个 coding agent 客户端，并且已经开始维护多份 MCP、规则、handoff 或工具配置。Brigade 的 catalog/sync 思路正好处理这种重复劳动。
第二类场景，是你想让 agent 工作留下可审计证据。命令、退出码、diff、receipt 和 outcome ledger，比“模型说它学到了”更适合团队环境。
第三类场景，是你在尝试把 agent workflow 从一次性聊天变成持续改进的本地流程。Brigade 的 memory、skills、cards、reconcile 都围绕这个目标设计。
第四类场景，是你接受 plain files 和 CLI 驱动的 workflow。Brigade 不靠后台 daemon，也不提供托管控制台；这对 local-first 用户是优点，对期待图形化 SaaS 的团队则不是。
需要注意的地方
第一，项目还很新。59 stars、4 forks，创建时间是 2026-05-13，虽然最近提交和 release 活跃，但外部案例还少。要先在非关键仓库里验证。
第二，概念很多。MCP catalog、stations、handoff、memory owner、outcome ledger、receipt、ratchet 都需要理解。它不是那种装上就只有一个命令的小工具。
第三，它会接触 agent 指令和工具配置。即使有 dry-run，也应该认真看 diff，尤其是已经有严格 AGENTS.md、MCP 配置或安全规则的仓库。
第四，生态还在快速移动。v0.21.1 的 release note 已经包含很多 station 和 adapter 变化，说明项目仍在密集塑形。采用时最好固定版本，并把 .brigade/ 里的状态纳入代码审查。
小结
Brigade 抓到的是一个很实际的问题：当 coding agent 从单个聊天窗口变成多个工具、多个会话、多个 MCP server 和多条记忆时，团队需要的不是更多“灵感”，而是一套能同步、验证、回滚的本地操作台。
如果你现在只用一个 agent，Brigade 可能显得过重。但如果你已经在维护多份 agent 配置，或者想让 agent 的改进建立在真实命令结果上，escoffier-labs/brigade 值得放进试验清单。它还早期，但方向清楚：让 agent workflow 留下收据，而不是只留下聊天记录。