并行与工具接入

Agent 很慢，一次任务跑几十分钟是常态。并行和工具接入都是在解决同一个问题：让它同时做更多事，同时少问你。

并行跑多份

模型是随机的，同一任务跑三份挑最好的，成功率明显高于跑一份。选择题式的重构、算法实现、文案改写都适合这么用。

另一种并行是拆任务：两个不重叠的功能、一个写代码一个写测试、一个实现一个做审查。前提是文件边界清楚，否则两边改同一个文件，合并时你得手工仲裁。

策略	场景	主要风险
同任务多份	结果不确定、需要挑选	审查成本乘以份数
不同任务	功能互不依赖	共享文件冲突
实现加审查	一份产出，一份找问题	审查方看不到你的意图

并行的真实成本在收尾：三份 diff 要读三遍，三次测试要跑三遍。任务本身越小，并行的净收益越低。

并行之前先把接口定下来，否则合并比一个人写两遍更慢。份数别超过你能审完的数量，挑结果时还要看改动大小——通过的份数里，可能有一份是改测试换来的。

用 worktree 隔离

git worktree 让同一个仓库挂出多个工作目录，每个目录可以检出不同分支。给每个 agent 一个目录，它们就不会互相覆盖未提交的改动。

git worktree add ../wt-a -b feat-a
git worktree add ../wt-b -b feat-b
git worktree list

git worktree remove ../wt-a    # 合并后清理

worktree 共享 .git 对象库，创建几乎不花空间和时间。但每个工作目录是独立的，node_modules、.venv、构建缓存都要各自装一遍，第一次跑测试会莫名失败。

• .env 与本地配置不会自动出现，启动前补一份，并确认 .gitignore 覆盖它们
• 删除前确认分支已合并，git worktree remove 遇脏目录会拒绝，--force 直接丢改动
• IDE 一次只索引一个目录，开多个窗口比在一个项目里切分支清楚

合并前在主干重跑一次全量测试。worktree 里的绿只代表它自己那个分支，合在一起可能是另一回事。目录名带上分支名，出问题时一眼能看出是谁的。

接入 MCP

MCP 是 Model Context Protocol，一个开放协议，把 agent 接到外部工具上。server 端暴露资源、工具和提示模板，agent 端把这些变成可调用的函数。

典型用法是跨系统：读 Notion 里的规格，起草实现计划写回新页面，再动手写原型。也能接数据库、监控、浏览器。目录站可以逛 Pulse 和 Glama，装之前先看它请求哪些权限。

接入方式	例子	权限面
内置工具	读写文件、跑 shell	本机用户权限
MCP server	Notion、数据库、浏览器	server 自身的凭据
命令行工具	gh、jq、curl	你的 $PATH 与环境

本地 MCP server 是 harness 拉起的子进程，拿的是你的 token 和文件权限。它的工具描述还会常驻上下文，装多了既费 token 又增加误调用概率，按项目开关比全局常开好。工具报错也进上下文，配置写错时会连续失败。

带写权限的 server 尤其要克制：连上生产数据库或工单系统后，一次误判就是真实的删除或群发。测试环境里玩，生产环境用只读凭据，配置文件也别把个人 token 写进仓库。

可复用提示

把反复用的流程写成模板：审查清单、发布步骤、测试补齐规范。早期工具把它做成独立功能，现在 Codex 和 Claude Code 都并入了 skills——描述常驻，正文按需加载。

写模板时注意几点：

• 放仓库里而不是工具配置里，才能随代码一起 review
• 模板要能跑通再存，过时的命令比没有更糟，也更容易误导人
• 分层：本次任务写进对话，跨项目复用写 skill，全仓默认写 AGENTS.md