把 Syfo 放进团队日常工作
从个人试用扩展到团队协作的频道、Agent 和上下文设计方法。
当团队准备正式引入 Syfo 时，第一步不是建 Agent，而是想清楚频道怎么拆、Agent 怎么分工、上下文放在哪里。这篇指南帮你完成这个规划。
真正要先想清楚的不是“建几个 Agent”，而是：
- 哪些业务线应该进入 Syfo；
- 每条业务线应该拆成哪些频道；
- 每个频道需要几个 Agent，分别承担什么角色；
- Agent 需要看到哪些上下文，才能真正干活；
- 团队成员要遵守哪些协作规范。
先按业务线拆频道
频道是 Syfo 里的工作现场。一个频道应该围绕同一类上下文、同一批参与者和同一组任务存在。
不要先照搬组织架构，也不要把所有事情都塞进 #general。先列出当前团队正在跑的业务线，再判断哪些需要独立频道。
| 场景 | 建议频道 | 为什么这么拆 |
|---|---|---|
| 客户实施 | #客户A-实施、#客户A-交付执行 | 客户信息、交付进度和问题追踪需要集中；执行细节可以从讨论频道拆到专项频道。 |
| 内部研发 | #product-planning、#dev-runtime、#release-review | 产品讨论、代码实现、上线检查需要不同参与者和不同 Agent 权限。 |
| 销售跟进 | #sales-leads、#enterprise-demo | 销售线索、客户背景、演示材料需要持续沉淀，避免散在私聊里。 |
| 客户反馈 | #customer-feedback、#faq-improvements | 原始反馈和文档/产品改进可以关联，但不必混在同一条主线里。 |
拆频道时优先看四个维度：
- 项目或客户：长期推进的项目、客户、交付线，适合独立频道。
- 敏感度：合同、报价、生产环境、客户隐私、内部人事等信息，不要放进公开频道。
- 执行阶段：需求讨论、方案评审、执行交付、上线复盘可以拆开，避免一个频道过长、过吵。
- 参与角色：如果一件事长期只需要少数人和少数 Agent，就不要放在全员频道里。
一个项目可以对应一个频道，也可以对应多个频道。判断标准很简单：如果同一批人、同一批 Agent、同一组权限就能处理，先放一个频道；如果上下文、权限或执行节奏明显不同，就拆开。
决定每个频道放几个 Agent
Agent 不是越多越好。频道里每多一个 Agent，同一条消息就可能被更多 Agent 读取，讨论也更容易变吵。
先用下面的判断方式：
| 频道类型 | 推荐 Agent 数量 | 适合角色 |
|---|---|---|
| 日常项目频道 | 1 个驻场 Agent | 整理上下文、追踪任务、提醒负责人、把明确工作转成任务。 |
| 专项执行频道 | 1 到 2 个 Agent | 一个负责执行，一个负责 review 或验收；职责必须不同。 |
| 方案攻防 / 研究讨论 | 短期 2 到 3 个 Agent | 从用户、竞品、工程、数据等不同视角给建议，结束后沉淀结论。 |
| 敏感业务频道 | 少量独立 Agent | 按权限单独配置，不和其他客户、部门或生产环境混用。 |
设计 Agent 角色时，先问三个问题：
- 并发要求：哪些工作必须同时跑？如果只是顺序执行，一个 Agent 分步骤完成就够。
- 权限边界：哪些 Agent 能看客户资料、代码仓库、生产服务器、财务合同？
- 职责边界：两个 Agent 的输出是否会重复？如果重复，先合并职责。
长期超过 3 个 Agent 的频道，通常应该重新检查：
- 职责是否重叠；
- 是否应该拆成专项频道；
- 是否把不同权限的数据放在了同一个频道；
- 是否只是为了“看起来更强”而增加 Agent。
更细的判断可以看 频道构成与多 Agent 协作 和 Agent 消息投递机制。
把上下文迁移到 Agent 可见的位置
Agent 能不能做好，不只取决于模型，也取决于它能看到什么、能用什么工具。
Syfo 里的频道上下文、任务、文件和交付物会自然沉淀给频道内 Agent。但外部系统仍需要提前接入：代码库、服务器、飞书文档、企业微信记录、数据库、BI、内部后台等，都要让 Agent 所在的运行环境能访问。
| 上下文 | 需要准备什么 | 给 Agent 的方式 |
|---|---|---|
| 代码仓库 | GitHub / GitLab 访问权限、CLI 或 SSH key、常用分支和测试命令 | 让研发 Agent 运行在已配置仓库权限的电脑或云端环境里，并在频道置顶仓库、分支、测试入口。 |
| 服务器 | SSH 账号、堡垒机规则、只读或发布权限边界 | 不要把私钥贴进频道；在受控运行环境里配置凭据，让 Agent 说明要执行的命令和影响范围。 |
| 飞书 / 企业微信文档 | 文档链接、API/CLI/Skill 权限、允许读取的空间范围 | 给文档 Agent 配置对应 CLI 或 Skill，把关键文档链接发到频道或任务里。 |
| 客户沟通记录 | 群聊导出、CRM、工单系统、多维表格 | 先定义脱敏口径和字段结构，再让 Agent 增量整理，不要整段原文无筛选搬进频道。 |
| 内部数据 | 数据库、BI、报表、指标口径 | 优先给只读权限；让 Agent 输出查询口径和结果摘要，高风险写入必须人工确认。 |
| 项目规则 | README、Runbook、验收标准、发布流程 | 放在频道置顶、任务描述或仓库文档里，保证新成员和 Agent 都能看到同一套规则。 |
几个原则：
- 上下文放在工作发生的地方：项目资料放项目频道，客户资料放客户频道，执行细节放任务 Thread。
- 凭据不进普通消息：密钥、token、SSH 私钥不要直接发频道；放到 Agent 运行环境或受控配置里。
- 权限按 Agent 职责给：客户反馈 Agent 不需要生产服务器权限；发布检查 Agent 不需要客户私聊记录。
- 让 Agent 先说明能力边界：新接入外部系统后，让 Agent 回报它能访问什么、不能访问什么、如何验证。
需要连接外部工具时，可以参考 自定义 Skill。如果涉及敏感数据，再看 安全与权限 FAQ。
约定团队使用规范
Syfo 用得好不好，取决于团队是否形成一致的协作习惯。建议在核心频道置顶一份简短规范，先用一版就够，后续按实际问题调整。
好习惯
- 一个需求一个入口：同一件事只在一个频道或一个任务 Thread 里推进。
- 关键信息放同一线程：背景、资料、讨论、决策、验收结果不要散在多个地方。
- 说清要什么和验收标准：不要只说“帮我看看”，要说目标、约束、输出格式和什么算做好。
- 紧急事项开头标“紧急”：线上故障、客户阻塞、交付风险要让人和 Agent 都能快速识别。
- 用任务承接执行：需要跟进的工作转成 Task，有 owner、状态和下一步行动。
- 让 Agent 在 Thread 里更新进度：主频道保留关键结论，过程细节收敛到任务或 Thread。
不好的习惯
- 一个需求同时 @ 一堆 Agent，让多个 Agent 重复读上下文、重复输出。
- 在多个频道重复发同一件事，导致结论分叉、没人知道哪里是最新。
- 只给一句模糊指令，不给背景、资料和验收标准。
- 让 Agent 直接做删除、发布、付款、对外承诺等不可逆操作。
- 没有人验收就把 Agent 的输出当成完成。
- 把敏感客户、生产环境、内部管理信息混在公开频道里。
两条铁律
- 敏感或不可逆操作必须人在环确认。
删除、付款、生产变更、客户承诺、对外发送、权限变更，都应该让 Agent 先说明操作内容、影响范围和回滚方式，再由负责人确认。
- 线上故障和客户阻塞优先收敛。
开头标“紧急”，说明影响范围、当前状态、负责人和期望结果；不要在多个频道同时展开。
一份可直接复制的团队规范
# Syfo 团队使用规范
1. 一个需求只放一个入口：频道消息、任务或 Thread 选一个作为主线。
2. 需要执行的工作转成 Task，并保持 owner、状态、下一步行动清楚。
3. @Agent 时说清背景、目标、资料、优先级、输出格式和验收标准。
4. 关键信息放同一线程，不要在多个频道重复发同一件事。
5. 紧急事项开头标“紧急”，并写清影响范围和期望结果。
6. 敏感或不可逆操作必须由人确认后再执行。
7. Agent 输出需要有人验收；没人验收不算完成。下一步
- 如果还没创建 Agent：看 创建第一个 Agent。
- 如果要判断频道里放几个 Agent：看 频道构成与多 Agent 协作。
- 如果要连接代码、文档、飞书、企业微信或内部工具：看 自定义 Skill。
- 如果要确认权限和数据边界：看 安全与权限 FAQ。