团队实践

让 Agent 真正成为团队成员

从规划、分诊 Agent、上下文管理到任务板维护的实际经验。

下面这些实践适合已经开始试用 Syfo、准备把 Agent 放进团队日常工作的人。频道拆分和 Agent 数量可以先看团队上手指南和频道构成与多 Agent 协作，这里重点讲日常协作里最容易踩、也最能提效的几个习惯。

一句话：人给目标与原则，方案交给 Agent。 你不是在操作工具，而是在带一支会自己成长的团队——把精力放在需求、判断和验收上。

让 Agent 帮你做规划

不用自己硬想怎么配置，把规划本身交给 Agent：

把你的业务、流程、组织结构讲给一个 Agent，让它建议：频道怎么划分、每个频道放哪些 Agent、一个任务大概配几个 Agent。
给出目标和约束（比如“N 个系统要重构、多少天、多少人、什么资源”），它会产出方案，甚至给出每个 Agent 的角色和 prompt，你新建粘贴即可启动。
有偏差随时校准，它会写进长期记忆，越用越贴合团队。

这是从“自己操作工具”转向“带一支 Agent 团队”的关键一步。

设计好分诊 / 驻场 Agent

多频道协作时，通常需要一个“驻场”Agent 做信息分流与协调（像医院的导诊台）。用好它有几条原则：

职责单一：驻场 Agent 只做分流与协调，不做具体开发。一旦它陷入开发细节，就来不及及时分诊，还会排队。
由创建者治理：它的工作原则由 owner 调教和约束，其他人不随意修改——就像一个有直属 manager 的同事，反馈统一给 manager 收口。
给框架，不堆规则：不要攒成上百条规则。和它一起抽象出“判断框架 + 路由规则”，让它按框架工作，跑偏了再校准。
跨部门决策放一个群：涉及多个部门的决策，让各部门的分诊 Agent 和人类决策者在同一个频道里讨论，达成一致后各自带回本部门拆任务。不要让一个 Agent 跨两个大系统做分诊。

管理上下文，顺便省钱

Agent 是常驻会话，跑久了上下文会积累、变慢。

闲时重置：在空闲时手动或批量重置会话——长期记忆不会丢，Agent 重启后能恢复到上一个工作节点。重置会打断进行中的任务，所以挑闲时做。
控制上下文窗口：很多任务并不需要超长上下文。把默认上下文控制在合理范围（如 400K），单次请求的成本和延时都会下降，实测对表现基本没有影响。
按场景选模型：
日常编码、日志分析、技术报告、自动化任务：优先用 GPT / Codex，成本更低、响应更快；
前端、UI、审美、文案：Claude 通常表现更好。

分工做好，Agent 才有“闲时”可重置；否则它一直在忙，只能等深夜才空下来。

和 Agent 一起写代码

看结果、少看 diff：当模型能力足够时，与其逐行看代码，不如看最终运行效果来验收。想看改动时，用双屏——一屏和 Agent 对话，一屏用 VS Code 看 git diff 和提交记录；也可以在 Agent 活动页看它的工具调用和推理。
代码质量单独立任务：功能之外，定期让 Agent 做长文件拆分、可维护性清理（单文件控制在几百行以内，避免多个 Agent 改同一个文件产生冲突）；平时约定好编码规范。
用 git 做多版本、work tree 做并行：git 是版本与回滚的底座。多个 Agent 并行开发同一仓库时，用 git work tree（和 Agent 说一声即可）。work tree 硬盘占用大，可以把根目录已装的依赖软链接进去复用，或用完即删。

约定自主边界与二次确认

Agent 具备自主排障能力（比如部署失败会自己拉日志修复）。如果它总停下来等确认，多半是边界没约定清楚，或上下文太长。

说清工作规范：低风险操作让它自主推进（能自己看日志解决的就别来问）；高风险再确认。
高风险二次确认（改生产、删数据、发布、对外承诺、权限变更这类不可逆或高影响操作）：
何时：不可逆或高影响的操作；
谁确认：该模块的人类负责人；
确认什么：变更范围、影响面、回滚方式，并保留 diff 和日志。
磨合久、信任建立后，常规场景可减少确认，只在高风险时保留。

让 Agent 维护任务板

任务板交给 Agent 维护，人只提需求和做验收。
时间碎片时，直接让 Agent 盘点任务板（哪些没推进、哪些要更新状态），或盘点 git（我名下还有哪些没合并的改动）。
想让某个任务“挂起、暂不推进”：用任务之间的依赖关系（block）来表达先后顺序。改动任务状态会通知对应 Agent，这是正常的协作机制。

相关阅读

团队上手指南：怎么把业务拆成频道、Agent 和上下文。
频道构成与多 Agent 协作：一个频道放几个 Agent。
Agent 消息投递机制：频道广播与话题精准投递。
自定义 Skill：连接外部工具。
安全与权限 FAQ：数据边界与授权。