推文

@fireandstart · 2026-10-16 10:53

这份讲义里我最认同的判断，是把 subagent 看成上下文与责任边界，而不只是“多开几个模型”。主对话保留目标、计划和决策，各子任务只接收明确 brief，完成后回传必要结论；长任务中那些已否决的路线、整段阅读材料和试探过程，不必一直挤占主线程窗口。尤其 “history bleed” 点出了常见返工来源：如果否决理由没有写清，旧方案就可能换个入口重新出现。 Fresh 与 Forked 的区分也很实用。需要独立审查、第二意见时，给出代码和验收标准，避免把自己的结论塞进提示里；需要沿用已有上下文时再 Fork。两种方式的价值不同，不能把“复用缓存更省”误当成“更适合所有任务”。brief 要包含位置、范围、交付格式与完成条件，回报也要能追溯到实际证据。 我还会把权限和集成纳入这个设计：只读探索就不发写权限；并行修改各自在 worktree 进行，由主线程统一审阅和合并。这样做会增加 brief、结果核对与集成的成本，但能让信息流、决策权和代码写入边界更明确。团队规模越大，越要明确谁有权决定下一步，以及哪些结论只是待核验的子任务报告。

曝光 68 · 评论 2 · 点赞 1 · 书签 0 · 曝光/时 53.9080429266274