我让 4 个 TRAE Agent 并行给仓衡做体检——顺便让它自己扫自己
参赛赛道：全链路开发实战
选题方向：多 Agent 并行协作
话题：#TRAE双端融合 #全新TRAE实战体验
写在前面
「仓衡 RepoBalance」是我用华为云码道独立开发并开源的 Rust + Tauri 2 桌面应用，做的事很简单：对本地 Git 仓库做健康度体检，看大文件、僵尸分支、提交习惯、依赖健康、敏感信息残留。代码托管在 AtomGit（G-Star 认证）和 GitHub。
它有个尴尬的地方：专门给别人仓库做体检，自己却从没被系统体检过。迭代到现在，crates/** 里已经攒了不少 unwrap()、零覆盖的公开函数和散落的 TODO，我平时靠人肉抽查，根本查不过来。
正好全新 TRAE 支持多 Agent 并行，我打算把这事交给它：4 个 Agent 按不同维度同时把全库扫一遍。扫完之后顺手做了个更有意思的实验——让仓衡的 CLI 把自己也扫一遍，看看 AI Agent 和体检工具各自能看到什么。本文记录的就是这次折腾的全过程。
一、分工设计：先约接口，再放并行
多 Agent 并行最容易翻车的地方，是各扫各的、最后拼不起来。所以我的第一句话术没有直接让它启动，而是先给定分工，再要一份任务书：
- Agent-1 错误处理审计：扫
crates/**的unwrap()/expect()/panic!，区分"测试代码可接受"与"生产代码应消除"； - Agent-2 测试覆盖盘点：对比 rb-core 各模块与现有测试文件，找出零覆盖的公开函数；
- Agent-3 规范一致性：rustfmt/clippy 执行情况、TODO/FIXME 散落、公开项文档注释缺失；
- Agent-4 汇总：等前三个完成后，合并成
reports/repobalance-health-report.md。
有两个约定不能少：每个 Agent 的输出文件路径各自独立，免得写冲突；Agent-4 必须等前三个都跑完再动手。TRAE 按这个分工给出了四个 Agent 的任务书和先后安排，我看过没问题才放行。
二、并行执行实录
前面说过，四个维度如果排队跑，本质上还是串行。这次任务的关键是让多个 Agent 真正同时在跑——从下面两张截图里能看到三个 Sub Coding Agent 同时处于「输出中/思考中」状态，我这边只需要盯进度、等结果。
跑完一轮下来：Agent-1 扫了 35 个 .rs 文件，六种模式命中 179 处（unwrap 176、expect 3），其中生产路径的违规只有 1 条——main.rs:29 Tauri 入口处的一个 expect，风险也低，rb-core 生产代码零命中；Agent-2 盘点出 55 个公开函数，直接覆盖 51 个、间接覆盖 3 个、没覆盖的只有 1 个（98.2%）；Agent-3 报出 fmt 不通过 3 个文件 15 处、clippy 0 warning、TODO 0、缺文档 5 处；最后 Agent-4 把三份中间产物合并成 132 行的报告。整个过程 19 分 17 秒。
关于报错，我在启动话术里加了一条：不许静默跳过，报错就停下把根因告诉我。这轮四个 Agent 全程没报错，这条规矩没派上用场——但踩坑小节的第 2 条说明为什么它必须一直写在话术里。
三、体检报告与"自己扫自己"
Agent-4 合并出的报告按模块分组统计，还给了 TOP 10 高频问题排行。比起问题数量，我更看重这个排序：unwrap() 集中在哪类模块、零覆盖函数集中在哪次迭代，一眼就能看出来。
报告到手后，我又加了一个环节：让仓衡的 CLI 把自己扫一遍。
cargo run -p rb-core --bin rb scan ./
两组结果摆在一起看挺有意思：TRAE Agent 扫的是代码质量维度（unwrap、覆盖、规范），仓衡扫的是仓库健康维度（提交习惯、依赖、大文件）。两边视角不重叠，结论也不打架——这正好说明多 Agent 分工扫的和传统 lint 工具扫的，确实不是一回事。
具体数字：仓衡自扫 93/100（0 Critical、4 Warning，全是 demo-repo 里故意埋的演示夹具）；Agent 侧报告 132 行，TOP 3 是 conflict_markers.rs 测试模块的 fmt 偏差 12 处（会卡 CI）、bin/rb.rs 9 个私有函数零测试、git/repo.rs 的 2 处折行，报告末尾给了 P0/P1/P2 共 7 条修复项。
这 7 条里我当场处理了一条：Agent-2 盘点出的那个零覆盖公开函数（VulnEcosystem::label），顺手补上单元测试，cargo test 211 条全过。体检报告如果不落地一两条，那就只是一份好看的成绩单——这也是我坚持在同一个任务里闭环的原因。
四、并行 vs 串行：实测对比
下表「4 Agent 并行」列是本次实测值；人工抽查和单 Agent 串行两列当时没有专门计时，只给量级参考：
| 指标 | 人工抽查 | 单 Agent 串行 | 4 Agent 并行（实测） |
|---|---|---|---|
| 覆盖率 | 小于 100%（抽样） | 100% | 100% |
| 耗时 | 半小时以上 | 半小时到一小时（推算） | 19 分 17 秒 |
| 产出物 | 无记录 | 4 份中间产物 + 1 份报告 | 同左（报告 132 行），且分工可复用 |
五、踩坑实录
1. 两个 Agent 写同一个文件会互相覆盖
现象：初版分工让各 Agent 都往一个汇总文件追加，出现内容丢失。
根因：并行写同一文件没有协调方。
解决：改为各写独立输出文件，Agent-4 单独负责合并。
教训：并行的前提是"写空间不重叠"，接口约定先于启动。
2. Agent 报错静默跳过比报错更危险
现象：某 Agent 扫描中断，若不盯进度，报告会以"缺一个维度"的假完整示人。
根因：默认行为是跳过继续跑。
解决：话术里明确"报错就停下告诉我根因"。
教训：给并行任务立"失败要出声"的规矩，报告可信度才成立。
3. 扫描规则的"违规定义"必须给例子
现象：Agent-1 把测试代码里的 unwrap() 也判为违规，误报一堆。
根因：规则只有一句话，没有正反例（"测试代码可接受"没有写进任务书）。
解决：补充豁免边界说明后重扫，误报消失。
教训：给 Agent 的检查规则要像给同事的评审清单一样带例子。
六、边界：Agent 并行做不了什么
这四个维度都是逐文件、规则明确的检查，正是并行最拿手的活。但有一种事 Agent 做不了：跨模块的语义判断——比如两个检查项对同一类异常的处理策略是否统一，Agent-1 到 Agent-3 各自扫各自的，谁都看不见全局，这类问题还是得人读完报告来裁。并行的价值在于把"机械覆盖"的成本打到接近零，把人留给真正需要判断的地方。
七、结论
这次实验跑下来，一套可以直接抄的流程就出来了：先给分工任务书（写清输出路径）→ 说清谁等谁 → 报错必须出声 → 汇总单独交给一个 Agent。4 个 Agent 并行，把一件我一直"排不上日程"的全量体检变成 20 分钟的例行操作，报告落在 reports/，以后每次迭代前后各跑一遍，代码质量的变化就不用靠感觉了。
"仓衡扫仓衡"的对比还有个意外收获：工具型开源项目最怕自己照不到自己，现在用 AI Agent 多维并行扫一遍，是我目前找到的最便宜的自检办法。
仓衡 RepoBalance：开源 Git 仓库健康度体检台（Rust + Tauri 2），atomgit.com/dickeryang/… 。多 Agent 体检话术见文内，可直接复用到任何工程。
