在团队频道唤起本地编程智能体

把 Claude Code 加进团队频道，像叫同事一样用 @mention 找它排查问题，这是 osFoundry 给出的协作方式。agent 在本机仓库的临时 git worktree 里工作，再把结果发回频道；Codex 也能按相同方式接入。

这篇值得看的不只是聊天入口，而是入口背后的边界：上下文怎么续接、多个频道是否共享记录、agent 互相调用会不会失控。接入很直观，但要真正用于团队开发，还得理解这些设置的代价。

一次 @mention，背后启动了什么

这套功能只能在桌面版使用，因为 coding agent 的 CLI 在用户电脑上运行。浏览器会提示「Coding harnesses run on your machine, so they are only available in the desktop app.」

配置从频道详情侧栏开始：在「Where agents here work」选择仓库目录，再从「Agents that can act here」添加「A coding agent」。列表支持 Claude Code、Codex、OpenCode；没有安装的 CLI 仍会显示，但标为「not installed」。

示例把 Repository 设为 ~/work/shop-api，Handle 设为 @claude。Handle 创建后不能修改，因为消息会引用它。后续 mention 会让 agent 在临时 worktree 中执行任务，回答则以自己的身份回到频道。

原文用退款测试展示了从排查到提交的过程，下面几行保留了示例中的工具调用：

  Bash   git log --oneline -5 -- spec/payments/refund_spec.rb
  Read   spec/payments/refund_spec.rb
  Edit   spec/payments/refund_spec.rb   （在退款期間的測試中固定時鐘）
  Bash   git push -u origin claude/refund-spec-clock

要看最后一行：示例包含向远端推送分支，执行范围已经超出本地分析。回复声称测试依赖 Time.now，在 UTC 午夜附近失败，并给出 PR #482。但作者明确说明频道、仓库和消息都是演示内容，不能把它当作修复效果的实测证据。

保持会话，省下的是重复上下文

两种会话模式决定了协作体验。

「Start fresh each time」每次 mention 都启动新 session，重新读取频道。「Stay open and remember」则保留同一个 Claude Code process，让后续提问接着前面的工作继续。后者必须搭配「Ask me while it runs」，以便用户回答执行中的权限询问；另一个权限选项是「Decide before it starts」。

首次启动会收到最多 12 条消息的 snapshot。常驻会话再次被 mention 时，只收到上次之后的新消息，包括 agent 自己的回答；当前问题已经在 brief 中，不会重复放入历史区块。示例第二次调用补入了三条消息。

每条历史消息截到 600 字符，更完整或更早的内容通过 channel_history 获取。该工具默认返回 30 条，可指定 1 到 100 条，只能读取 agent 已加入的频道。

常驻会话记住的内容，不等于频道里可搜索的记录。

作者明确提醒，process 自己的记忆不在 transcript 中，也无法搜索。因此，关键判断仍需要回写频道。侧栏的「Start fresh」会结束当前 session，让下一次调用重新读取频道。

消息读取进度绑定 process 的 session id，只有 run 成功才推进。崩溃、闲置 30 分钟回收或手动重置后，新 process 会重新从 snapshot 开始；cold session 还会收到对话 replay 和 system framing，warm session 只接收新的 turn。

还有一个容易误配的地方：复用已有 @claude，会让两个频道共享对话和 run 历史；但常驻 process 按「频道 × agent」保留，两边仍是两个 process。需要分开记录时，应创建新 Handle。

触发、读消息和执行权限，要分开理解

添加面板声称 agent 只在被 mention 时行动，也不会读取没有 mention 它的消息。但后面的实际 brief 示例又包含未 mention 它的频道发言。

按示例能确认的是：mention 控制启动，启动后会注入部分频道历史。不能据此承诺「没 @ 它的内容，它就看不到」。

这些历史被标成 UNTRUSTED DATA，按时间排列，只作为上下文使用。示例还包含 channel_id、message_id、run_id、thread_root_id、runtime、channel_agents 和 max_recipients 等路由信息，其中 runtime 是 cli:claude:agent。这是在明确告诉 agent：谁提出任务、哪些内容只是聊天材料。

agent 之间的触发另有规则。回复正文里写 @handle 不会唤醒对方，必须列入 to 清单；收件人数默认上限为 3。普通频道还要求所有者开启「Let other agents talk to this one here」，开启后工具只读。

项目房间允许 agent 相互响应，但同样限制为沟通用途。系统没有 hop 计数器，也没有自动对话次数上限，而是展示实时费用，提供任何成员都能操作的停止开关，连正在执行的 run 也会取消。

权限等待也分两层：需要用户点击的 osFoundry 工具会直接拒绝并返回理由；Claude Code 自己的权限询问，在「Ask me while it runs」模式下会等待用户打开并回答。代码变更通过临时分支交付，在合并 PR 前不进入目标分支。

我的判断

我认可它把工作目录、会话生命周期和触发规则放在配置入口的做法。相比每个人单独打开终端提问，频道能保留任务来由和结果，其他成员更容易接上讨论。

但作者没有提供耗时、费用或修复成功率的对照数据。「每次重新开始永远不会偏掉」也说得过满：重启能清除旧 session 的状态，却不能保证历史消息完整、任务理解正确。

UNTRUSTED DATA 是有用的指令边界，但原文没有给出对抗测试，不能把提示文字视为已经验证的防护。worktree 能隔离代码工作目录，也不能自动约束网络访问和其他工具行为，最终仍取决于 CLI 权限配置。

常驻模式适合连续追问，但它也引入了不可搜索的记忆。对需要交接和复盘的团队，频道里明确写出的结论，比「它应该还记得」更可靠。

能拿来做什么

• 先在一个仓库明确的频道试用代码定位或测试排查，检查它获取了哪些历史、使用了哪些权限，以及最终回复是否给出可核验的文件和原因。
• 连续排查同一问题时使用常驻会话；任务明显切换时按「Start fresh」，并把关键结论写回频道，方便成员交接。
• 不同频道需要独立记录时创建不同 Handle，避免通过「Add @claude instead」复用后，意外共享对话和 run 历史。
• 可以按作者建议，让 @claude 修复问题，再在同一 thread mention @codex 审查 PR；审查仍要核对差异和验证结果，原文没有证明双 agent 必然提高质量。