和 Helena 聊了聊 Raft

前几天突然有人加我，说自己在上纽大任教，想做一个 Raft 相关的访谈。她是 Helena Rong（戎航），上海纽约大学互动媒体与商学助理教授，关注去中心化 AI、信任基础设施，以及人与 AI 的集体未来。

刚好我最近也有一些相关的想法，所以就硬着头皮接受了这次线上访谈。没想到最后聊得还挺开心。

以下是我们这次访谈的一些总结：

一句话结论

Raft 真正让 idan 留下深刻印象的，不是“多几个 Agent”，而是让 Agent 在群聊里像同事一样判断何时说话、如何参与协作；但稳定性、单 Agent 串行、无法进入既有 IM、数据迁移与本机隐私问题，使他最终放弃平台，转而把 Raft 的交互和上下文设计移植到自己的飞书 + 本地仓库 + Claude Code 工作流中。

用户画像

程序员，AI 创业公司从业者，已高度依赖 Coding Agent。
强调本地数据控制、上下文可迁移和可追溯，对平台锁定与隐私泄露敏感。
对 Agent 持工具理性：有身份的 Hermes（二蛋）是“秘书/下属”，Coding Agent 是纯执行工具；不会因长期使用产生情感依赖。
已从“自己读代码”转向“管架构、看结果、让 Agent 互相验证”。他说自己约半年不看具体代码，主要通过测试报告、录屏、部署结果验收。

使用 Raft 的路径

idan 通过 OpenCLI 社群及作者/群主的持续推荐接触 Raft（早期名为 Slock），使用约两三个月。最初吸引他的有两点：界面好看，以及“把 Agent 当同事”的群聊设计。相比需要主动触发的 IM Agent，Raft 的 Agent 会判断什么时候该回复、什么时候不该回复，这种参与感更接近真实同事（00:35–02:48）。

他的实际用途并不只限于写代码，也包括记笔记、写小红书稿和处理生活事务；同时还会使用 CodeBuddy、Claude Code 等工具（01:40–02:17）。

为什么弃用 Raft

稳定性不够。 他多次提到 Bug 较多，无法放心把同事拉进平台，更难作为公司级工作环境推广（03:39–05:07）。
Agent 不能并行。 他曾配置约 10 个 Agent，但其中许多只是为了绕过串行限制而复制的同角色 Agent；真实需求往往并行，这是明确的弃用原因（08:34–08:52）。
无法融入既有 IM。 团队日常在飞书协作，Raft 的聊天必须留在自己的平台内。把全体同事迁进去不现实，除非由老板自上而下采购和推动（26:46–27:06，35:25–36:42）。
本机连接带来隐私与组织部署障碍。 Agent 连接个人电脑，员工不会自然愿意开放本机数据；个人使用可以自下而上扩散，公司级采用则需要权限、采购与治理（04:43–05:03）。
迁移成本和数据控制。 idan 有“数据洁癖”，希望任务、上下文、证据都留在自己维护的仓库里，能被不同 Agent 读取，而不是绑定在某个平台中（05:55–07:07）。

值得注意的是，他并没有否定 Raft。弃用后，他仍主动复刻了 Raft 的群聊、Channel 上下文和回复约束，说明产品核心体验成立，但交付形态和基础可靠性没有跟上。

idan 当前的 Agent 工作流

1. 仓库是共享真源

每个任务都记录需求、Agent 做过什么、测试是否通过，以及前端录屏等验收证据。Claude Code、Hermes 等不同 Agent 都读取同一个本地仓库，从而实现跨工具共享上下文，而不是依赖某个 Agent 的会话记忆（05:55–07:07）。

2. 规划—执行—验证

一个需求会经历多轮“规划、执行、验证”：先与 Coding Agent 澄清需求并落入任务目录，再派 Sub-agent 分别实现与验证，最后要求测试报告、录屏或可见结果。idan 不以阅读代码作为主要验收方式，而是看最终行为是否符合要求（07:11–08:08）。

3. 有人格的秘书与无人格的工具分工

目前真正有稳定身份和人格的只有 Hermes，昵称“二蛋”。它负责在飞书中代替 idan 与同事沟通、读取需求文档、远程调用 Claude Code、查看任务是否中断。Coding Agent 没有固定名字，按任务临时派生 Sub-agent（09:19–10:26，12:33–13:45）。

这意味着 Hermes 目前更像跨设备入口、秘书和状态中继，还不是一个成熟的“管理多个长期 Agent 的总管”。旧纪要把它描述成动态统筹多个 Agent，略微夸大了当前成熟度。

4. AI 写代码，AI 审 AI，人做架构与兜底

idan 主要检查架构是否合理和结果是否通过，而不是逐行审代码。为了防止 Agent 急于交付，他会让另一个 Agent 做代码审查、部署和测试，形成对抗式验证。人工主要在测试工具失效、鉴权、API Key 过期和上下文不足时介入（约 29:00–34:00）。

记忆与“蒸馏自己”

idan 的长期目标是把自己的不同能力蒸馏到不同 Agent 中，而不是立刻做一个覆盖全部人生的超级 Agent。工作上下文被持续维护在专门仓库里，随着资料积累，一个需求所需的沟通轮次可以从十几次降到三四次（10:46–12:24）。

他会通过定时任务总结每天与 Agent 的对话，再更新上下文仓库；但尚未把会议、日常交流等所有个人数据纳入。核心瓶颈不是上下文窗口长度，而是外置记忆是否能在正确时机唤起正确经验，以及用户是否愿意持续整理、蒸馏信息（约 20:30–22:00，34:00–35:20）。

对纯执行型 Coding Agent，他反而关闭长期记忆，避免模型自行注入错误或无关记忆，只允许其使用当前工作目录的上下文（37:19–37:42）。这显示“记得越多越好”并不是他的原则，可控、分域、按需唤起才是。

群聊 Agent 的真实难点

idan 已把 Raft 的部分机制移植到 Hermes：收到消息时附带所在 Channel、发送者和回复要求，用硬编码 Prompt 告诉 Agent 当前是群聊还是私聊、何时应当说话（25:09–26:35）。

但技术上知道“我在群里”还不够。Hermes 的记忆长期来自一对一聊天，没有形成多人环境中的社会角色，因此出现过两类问题：

回答机械，像“为了完成任务而回复”，不像真实秘书或同事。
被要求自我介绍时，把 idan 与它的内部协作方式直接说给群里的人，暴露了不该公开的信息（22:01–24:08）。

因此群聊 Agent 需要的不只是 Channel 字段，还包括：信息披露边界、不同关系下的话语策略、发言时机、权限范围、事后反馈学习，以及稳定的人格与职责边界。

对模型、Harness 与人格的判断

出错时，idan 优先检查上下文和 Workflow，而不是把问题归因于“模型降智”，因为前两者是自己能控制的（43:47–44:19）。
好的 Harness 能让较弱模型守住可交付基线，但不能抹平与顶级模型在细节上的差距（45:00–45:34）。
工具选型也受企业报销影响；公司报销 CodeBuddy 和 Claude Code 后，他基本不再使用国产模型（44:19–45:00）。
他不追求人格自然生长或情感关系。对 B 端客户而言，AI 先要创造价值、解决问题；拟人化是在此之后的增强项，而非购买理由（46:35–47:11）。

Raft 留下的最大价值

被问到最大回报是时间、质量还是能力时，idan 没有选择这些量化指标。他认为最大的收获是亲自感受到“Agent 同事”这种交互在工作中的必要性，并因此想研究相关产品，卖给希望进行 AI 转型的老板（45:36–46:34）。

这说明 Raft 的核心价值不是单点效率工具，而是让用户预演了一种新的组织协作关系。

产品机会（基于访谈的推断）

把“AI 同事体验”带进现有 IM，而不是要求组织迁移。 飞书、Slack 等应是入口，平台负责身份、上下文、权限和任务编排。
并行与可观察性是基础能力。 用户需要同时运行多个任务，看到状态、证据、失败原因与人工接管点，而不是复制多个同角色 Agent。
本地执行与企业治理必须同时成立。 既要让 Agent 操作个人电脑，也要提供最小权限、数据隔离、审计和管理员策略，解决员工隐私与老板采购之间的矛盾。
记忆应分域、可控、可迁移。 工作目录、个人偏好、群聊关系和敏感信息不能混成一个无限记忆池。
群聊安全比“像人”更优先。 不泄露内部协作、不替主人越权承诺、知道何时闭嘴，是同事感成立的前提。
先交付价值，再谈人格。 B 端的购买依据是解决问题和可衡量结果；人格的作用是降低沟通成本与提高协作自然度，而不是陪伴本身。