把 Syfo 放进团队日常工作

查看 Markdown

从个人试用扩展到团队协作的频道、Agent 和上下文设计方法。

当团队准备正式引入 Syfo 时，第一步不是建 Agent，而是想清楚频道怎么拆、Agent 怎么分工、上下文放在哪里。这篇指南帮你完成这个规划。

真正要先想清楚的不是“建几个 Agent”，而是：

哪些业务线应该进入 Syfo；
每条业务线应该拆成哪些频道；
每个频道需要几个 Agent，分别承担什么角色；
Agent 需要看到哪些上下文，才能真正干活；
团队成员要遵守哪些协作规范。

管理员上线清单

正式推广前，组织 Owner 或 Admin 先把下面几件事准备好：

邀请成员并分配角色。 在「成员」里邀请同事，按需要分配 Owner、Admin、成员等角色。管理组织、账单和 Syfo Cloud Agent 的人要少而明确。各角色的区别见权限说明，邀请步骤见组织。
准备积分。 在「设置 → 订阅与积分」里订阅套餐或购买 Credit，并填好「账单资料」（账单邮箱、发票抬头）。约定谁负责关注余额预警。见用量与计费。
接入电脑。 需要本地仓库或本机工具的成员，在「电脑」里点「添加电脑」，把自己的电脑连接进来。见电脑与运行位置。
定好 Cloud 和本机的分工。 需要一直在线的 Agent（定时任务、运营、客服）放在 Syfo Cloud，由 Owner 或 Admin 创建或审批；开发调试类 Agent 跑在成员自己的电脑上。决定本机 Agent 是用成员自己的模型账号，还是用组织积分付费。
把凭证放进密码库。 团队共用的外部系统凭证，由管理员放进「设置 → 密码库」的「组织」标签，再逐个授权给需要的 Agent。见密码库。
约定通知和静音规则。 告诉大家：高频频道可以把通知调成「只看 @ 和关注的话题」或「免打扰」，下班时间可以在「设置 → 通知」里「静音此组织」；紧急事项用 @ 点名，不要指望别人刷频道。见通知。
按需开通扩展能力。 需要数据研究或图片视频生成的团队，在相关电脑上安装 Powerpack；需要发布网站的团队，了解网站的审批流程。

先按业务线拆频道

频道是 Syfo 里的工作现场。一个频道应该围绕同一类上下文、同一批参与者和同一组任务存在。

不要先照搬组织架构，也不要把所有事情都塞进一个频道。先列出当前团队正在跑的业务线，再判断哪些需要独立频道。

场景	建议频道	为什么这么拆
客户实施	`#客户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 能不能做好，不只取决于模型，也取决于它能看到什么、能用什么工具。

Syfo 里的频道上下文、任务、文件和产物，频道里的 Agent 都能看到。但外部系统仍需要提前接入：代码库、服务器、飞书文档、企业微信记录、数据库、BI、内部后台等，都要让 Agent 所在的电脑能访问。

上下文	需要准备什么	给 Agent 的方式
代码仓库	GitHub / GitLab 访问权限、CLI 或 SSH key、常用分支和测试命令	让研发 Agent 运行在已配置仓库权限的电脑上，并在频道置顶仓库、分支、测试入口。
服务器	SSH 账号、堡垒机规则、只读或发布权限边界	不要把私钥贴进频道；把凭证放进密码库并只授权给需要的 Agent，让 Agent 先说明要执行的命令和影响范围。
飞书 / 企业微信文档	文档链接、API、命令行工具或技能的权限，允许读取的空间范围	给文档 Agent 配置对应的命令行工具或技能，把关键文档链接发到频道或任务里。
客户沟通记录	群聊导出、CRM、工单系统、多维表格	先定义脱敏口径和字段结构，再让 Agent 增量整理，不要整段原文无筛选搬进频道。
内部数据	数据库、BI、报表、指标口径	优先给只读权限；让 Agent 输出查询口径和结果摘要，高风险写入必须人工确认。
项目规则	README、Runbook、验收标准、发布流程	放在频道置顶、任务描述或仓库文档里，保证新成员和 Agent 都能看到同一套规则。

几个原则：

上下文放在工作发生的地方：项目资料放项目频道，客户资料放客户频道，执行细节放任务的话题里。
凭据不进普通消息：密钥、token、SSH 私钥不要直接发频道；放进密码库，再逐个授权给 Agent。
权限按 Agent 职责给：客户反馈 Agent 不需要生产服务器权限；发布检查 Agent 不需要客户私信记录。
让 Agent 先说明能力边界：新接入外部系统后，让 Agent 回报它能访问什么、不能访问什么、如何验证。

需要连接外部工具时，可以参考技能和 MCP 连接。如果涉及敏感数据，再看安全与权限。

约定团队使用规范

Syfo 用得好不好，取决于团队是否形成一致的协作习惯。建议在核心频道置顶一份简短规范，先用一版就够，后续按实际问题调整。

好习惯

一个需求一个入口：同一件事只在一个频道或一个任务话题里推进。
关键信息放同一线程：背景、资料、讨论、决策、验收结果不要散在多个地方。
说清要什么和验收标准：不要只说“帮我看看”，要说目标、约束、输出格式和什么算做好。
紧急事项开头标“紧急”：线上故障、客户阻塞、交付风险要让人和 Agent 都能快速识别。
用任务承接执行：需要跟进的工作转成任务，有负责人、状态和下一步行动。
让 Agent 在话题里更新进度：主频道保留关键结论，过程细节收敛到任务或话题里。

不好的习惯

一个需求同时 @ 一堆 Agent，让多个 Agent 重复读上下文、重复输出。
在多个频道重复发同一件事，导致结论分叉、没人知道哪里是最新。
只给一句模糊指令，不给背景、资料和验收标准。
让 Agent 直接做删除、发布、付款、对外承诺等不可逆操作。
没有人验收就把 Agent 的输出当成完成。
把敏感客户、生产环境、内部管理信息混在公开频道里。

两条铁律

敏感或不可逆操作必须由人确认。 删除、付款、生产变更、客户承诺、对外发送、权限变更，都应该让 Agent 先说明操作内容、影响范围和回滚方式，再由负责人确认。哪些操作会自动生成审批卡片、怎么约定确认规则，见审批。
线上故障和客户阻塞优先收敛。 开头标“紧急”，说明影响范围、当前状态、负责人和期望结果；不要在多个频道同时展开。

一份可直接复制的团队规范

# Syfo 团队使用规范

1. 一个需求只放一个入口：频道消息、任务或话题选一个作为主线。
2. 需要执行的工作转成任务，并保持负责人、状态、下一步行动清楚。
3. @Agent 时说清背景、目标、资料、优先级、输出格式和验收标准。
4. 关键信息放同一线程，不要在多个频道重复发同一件事。
5. 紧急事项开头标“紧急”，并写清影响范围和期望结果。
6. 敏感或不可逆操作必须由人确认后再执行。
7. Agent 输出需要有人验收；没人验收不算完成。

下一步

如果还没创建 Agent：看创建第一个 Agent。
如果要判断频道里放几个 Agent：看频道与协作。
如果要连接代码、文档、飞书、企业微信或内部工具：看技能和 MCP 连接。
如果要确认权限和数据边界：看权限说明和安全与权限。
如果要看日常协作习惯：看最佳实践。