团队抵触往往来自“蒸馏自己”的直觉：好像要把个人经验交出去，然后被替代。可以先绕开这个感受，把 agent 用在没人愿意做、又必须做的信息搬运上——跨系统找数据、整理格式、生成附件、回复邮件这类事。人只负责定义目标、做取舍、判断质量、承担后果。当同事发现 agent 接手的是这些琐事，而不是他的判断力，抵触会小很多。可以先挑一件团队里最频繁、最标准化的搬运任务，让 agent 跑通一次，看同事的反应是“省事了”还是“被替代了”⁠1。

如果每个人踩过的坑下个月还要再踩，agent 就只是多了一个工具，推广自然没动力。把一个人验证过的做法变成模板、把反复确认过的判断原则和边界写进共用文件，新人不用从零开始，老手也不用每次重讲。这样 agent 的能力不再依赖某个高手在线带着跑，而是变成团队级的基础设施。推广时可以先问：现在团队里有没有一个大家都认可的、反复出现的任务类型？从它开始沉淀，比先讲架构更容易被接受⁠2,3。

管理 agent 时容易有一种倾向：任务复杂就多开几个 subagent，像旧组织里“项目重要就多派人”。但多个 agent 常常来自同一个模型、继承相似上下文，容易犯相关性很高的错误，五个相似 agent 不自动等于五种独立判断。每多一个分支还多一份上下文和协调成本。判断该不该拆，先看这件事能不能被真正分解，而不是先把并行当成质量。团队推广时也一样，先证明一个 agent 在具体任务上稳定产出，比铺开一堆 agent 更有说服力⁠4。