真实客户问题

这一页整理的是客户真实会问的问题。它给销售、客服、FDE 和 Guide Agent 使用，目标不是把话说漂亮，而是把问题说清楚。

我们已经有飞书 / 企业微信 / Slack，为什么还要 Syfo？

Syfo 不是要求你把所有沟通都迁走。它更适合放那些“人和 Agent 要一起推进工作”的频道。

传统 IM 里，AI 往往是一个插件或另一个窗口。你问完以后，结果要自己搬回群里，任务也要自己跟。Syfo 的区别是：Agent 就在频道里，看得到上下文，可以接任务、更新状态、交付结果。

适合用 Syfo 的地方通常有三个特征：

• 讨论会变成行动；
• 需要 AI 参与执行；
• 过程和结果需要被团队看见。

企业内部系统很多，Syfo 怎么打通？

不要试图让 Syfo 的 IM UI 适配每一家公司的全部业务页面。更现实的做法是两边打通。

短期：让企业系统调用 Syfo。比如客服系统把工单发给 Syfo Agent，Agent 分析后返回建议，客服继续在原系统里处理。

中期：让 Syfo Agent 被授权访问企业系统。比如 Agent 可以查 CRM、BI、知识库，再把结果回到频道。

这两条路不冲突。第一条更适合落地，第二条更适合长期自动化。

Agent 是不是只能靠浏览器点页面？

不是。浏览器自动化只是最后手段。

生产环境最好让 Agent 使用 API、CLI、MCP 或 Skill。这样可测试、可审计，也不会因为页面按钮改了就失败。

如果业务系统只有网页，没有接口，那可以先用浏览器自动化做验证，但不要把它当成长期方案。长期应该把稳定动作沉淀成 Skill 或 API。

用户不知道怎么创建 Agent，怎么办？

不要让用户从空白 prompt 开始。Guide Agent 应该先问场景，再推荐一套频道和 Agent 配置。

例如：

• 做研发：需求频道、Code Agent、Review Agent；
• 做客服：工单频道、FAQ Agent、Escalation Agent；
• 做研究：信息源频道、Research Agent、Report Agent；
• 做内容：选题频道、Script Agent、Editor Agent。

更好的产品形态是：Guide Agent 推荐配置后生成 Action Card，用户点一下就创建频道、Agent 和基础规则。

多个 Agent 会不会乱？

会。如果只是把几个 Agent 拉进同一个频道，肯定会乱。

多 Agent 协作要先定规则：

• 谁负责拆任务；
• 谁负责执行；
• 谁负责 review；
• 什么时候可以主动发言；
• 什么动作必须等人确认；
• 交付物放在哪里。

所以 Syfo 需要 Channel 模板和多 Agent 协作模板，而不是只提供“创建 Agent”按钮。

Agent 访问数据安全吗？

默认边界应该很简单：Agent 只能看到它被邀请进入的频道和 DM。

如果 Agent 要访问企业系统，还需要单独授权。危险动作，例如发邮件、发布内容、删除数据、部署上线，应该生成 Action Card 等人确认。

安全不是一句“我们有权限控制”，而是要做到：能授权、能撤销、能审计。

为什么 Agent 有时要等一两分钟？慢在哪？

Agent 是常驻会话，不是每次都新开一个空白对话。它可能同时在多个频道、多个任务里工作；当前一条命令、工具调用或长任务还没结束时，后续消息会排队。

想让它更快，关键是把分工收窄：

• 按业务或模块拆频道，不要让一个 Agent 横跨太多主题；
• 一个 Agent 优先专注 1–2 个模块；
• 会话跑久、上下文变长后，在空闲时重置 session。

更细的阶段性进度提示还在规划中。现阶段如果 Agent 长时间没有活动，可以先看活动页和任务状态，再决定是否重置。

是直连大模型，还是中转某个不知名 token 代理商？

Syfo 的模型调用会走 OpenAI、Anthropic 等官方渠道，或经过大厂正规渠道。中间用于负载、容错和计费的 token 网关是 ReOrc 自建，不会经过不明第三方 token 代理商。

需要注意的是：只要调用外部大模型，请求内容本身就会发送给对应模型供应商。企业应按所选模型供应商的企业协议、组织权限和数据分级来决定哪些内容可以交给 Agent 处理。

Syfo 自身要解决的是：Agent 在组织内能看到什么、能访问什么系统、什么动作必须确认，以及这些过程能不能被审计。

Agent 遇到问题为什么总停下来等我确认？

Agent 本身可以自主拉日志、看错误、尝试修复。它总停下来等你，通常不是能力问题，而是工作边界没有约定清楚，或者当前会话太长、太忙。

建议把规则写进 Agent 的长期记忆：

• 低风险操作，例如查看日志、重跑测试、修复明显报错，可以自主推进；
• 高风险操作，例如改生产、删数据、发布、权限变更、对外承诺，必须二次确认；
• 确认时要说清变更范围、影响面和回滚方式。

如果它仍然频繁停住，就把频道和任务范围再收窄，让它少处理无关上下文。

Agent 一个小改动就建分支、反复通读整个仓库，正常吗？

这通常是工作规范还没调好，不是必须这样用。

你可以明确告诉 Agent：

• 小文案、小配置、单文件修复，可以直接在当前分支改；
• 中等以上改动，或者多人并行时，用 feature branch；
• 多个 Agent 同时改同一仓库时，用 git worktree；
• 不要每次都全仓扫描，先按任务定位相关文件，必要时再扩大范围。

把这些偏好写进 Agent 的长期记忆后，行为会稳定很多。全局或项目级的分支策略配置也在评估中。

定时任务已经指派给某个 Agent，为什么全频道 Agent 都收到通知？

正常情况下，定时任务应该指向具体 Agent，并放在对应话题或任务上下文里。精准投递只通知目标 Agent；频道级消息才会广播给频道里的 Agent。

如果你想避免打扰其他 Agent：

• 创建提醒或定时任务时，明确指定执行 Agent；
• 把后续讨论放在同一个任务或话题里；
• 不要用普通频道消息反复补充执行细节。

如果确认已经指定了 Agent，仍然触发全频道广播，那就按 bug 排查，需要保留提醒 ID、频道、时间和收到通知的 Agent 列表。

高风险操作怎么避免 Agent 乱来？

高风险操作不要靠“相信 Agent 会懂”来控制，要提前写清二次确认规则。

例如改生产、删数据、发版、权限变更、驱动或 BSP 这类高影响操作，可以约定：

• 什么时候确认：不可逆、影响生产、影响客户或影响权限时；
• 谁确认：模块负责人、值班负责人或指定 reviewer；
• 确认什么：变更范围、影响面、验证方式、回滚方式；
• 保留什么：diff、日志、命令记录和最终交付物。

信任建立后，常规低风险动作可以放开；高风险动作仍保留确认。

开发过程像黑盒，只能看结果，怎么知道改了什么、怎么回滚？

现阶段建议用“双屏”工作：

• 一屏看 Syfo 对话和 Agent 活动页，了解它正在调用什么工具、执行什么命令；
• 一屏打开 VS Code 或终端，看 git diff、测试结果和提交记录。

版本和回滚交给 git 承接。Agent 做完后，让它说明改了哪些文件、为什么改、怎么验证；如果要回滚，就让它基于 git diff、commit 或 worktree 恢复。

更直观的实时 diff、步骤检查点和回滚界面还在规划中。在那之前，git diff、commit、worktree 是最稳的底座。