ARTICLE · 1153674
给每个人配 AI 助手后,Every 为什么又转向了共享 Agent?|Every
本文：4281字，预计阅读时间：10分钟
团队采用 AI 的下一道难题，是让有效的方法能被别人调用，让重复的审核能被提前完成，同时把真正需要拍板的部分交还给负责人。
这篇文章基于 Every 近期博客的公开可读部分、早期产品回顾和官方产品页展开。
01 一人一个助手，为什么没有自然变成团队能力？
Every 的转向，在 5 月的一篇产品回顾里就已经露出端倪。
他们曾通过 Plus One，把一批基于 OpenClaw 的个人助手放进 Slack。设想很好理解：每个人都有自己的 AI 助手，帮自己处理事务，整个公司的效率也就随之提高。
但 Brandon Gell 和 Willie Williams 在文章中承认，早期内部使用带来的挫败感超过了效率收益。
有的助手明明接好了应用，却说自己没有连接；有的任务以终止消息收场；要让它们按预期工作，还需要持续维护。
文章也保留了成功的局部：Katie 的助手帮助她加快写作，Dan 的助手能管理一款产品的缺陷报告和功能请求。因此，不能把这个案例读成“个人助手没有价值”。
它暴露的是另一个问题：个人工作流有效，和团队工作流可复用，中间隔着一段很长的距离。
一个人用得顺手，往往因为他掌握了大量没有写出来的知识：文件在哪里，某句话实际上意味着什么，哪一步通常会失败，最后的结果怎样才算合格。
他可以及时补一句话，也知道什么时候该重来。同事却未必拥有这些上下文。
把同一份提示词发给同事，只完成了文字的转交。数据访问、执行环境、质量标准、故障处理和维护责任，都还没有转交。
因此，“公司有多少人在用 AI”只能描述采用的广度。要判断能力有没有留下来，还应该问：创建者不在场时，其他人能否独立完成同一类任务？
如果答案是否定的，团队增加的可能主要是个人技巧，组织对这些人的依赖并没有降低。
02 共享 Agent 的价值，藏在一次工作如何被旁观和复用
Dan 在 10 月 6 日的发布文里，把共享 Agent 的作用说得很具体：在大家已经工作的 Slack 中公开使用，让同事看到有效的 AI 工作流怎样发生。
这是一种传播方式的变化。
过去推广一个新工具，常常需要先解释能力，再发教程，然后期待别人抽时间尝试。共享工作环境可以让人直接看到：同事提出了什么请求，AI 用了哪些材料，产出了什么，哪里被人改过。
对一个没有时间研究 AI 的运营同事来说，看到“刚才那个项目已经生成了一份可审阅的计划”，通常比看到“这个工具很强”更容易判断是否值得试。
不过，把 Agent 放进群里只是入口。真正值得分析的是，一次工作能否留下下一次可用的方法。
Every 的产品页展示了一个很小的例子：Agent 更新团队成员页面，审核者要求个人简介少于 50 个英文单词；Agent 修正后，把这条要求保存进工作流；下一次添加成员时，沿用这个约束。
这是官方展示，不能据此认定它在真实客户环境中已经稳定运行。但它清楚表达了产品想实现的反馈机制。
如果一次修改只停留在聊天记录里，下一位同事仍然可能踩同一个坑。若修改被确认后进入可复用的工作方法，团队才可能减少重复解释。
由此可以给“共享”设一个更严格的标准：
同事能找到并调用这个方法； 方法带着必要的输入要求和验收标准； 一次审核发现的问题，有明确方式进入后续版本； 下次任务能验证这次修正是否生效。
这也是我认为共享 Agent 比“多人共用一个聊天窗口”更值得讨论的地方。它有机会把工作中的反馈变成资产。
这里的“共享”是共同入口、工作方法和受控反馈，不意味着所有人应该看到所有数据。访问客户资料、合同或财务信息，仍然应当沿用各自的权限边界。
03 真正该计算的，是每个可用结果花了多少代价
10 月 7 日，Every 的一篇文章把重点放在 Agent 的 token 效率上。公开导语说明，因为产品宣称 token 零加价，减少消耗可以直接减少用户支出。
这是合理的工程目标，但评估团队 AI 时，只看 token 仍然会漏掉大头。
一份只花很少模型费用的方案，如果需要负责人花很久重写，并不一定便宜。一个看上去已经完成的任务，如果还要有人反复确认有没有漏掉条件，也不一定省力。
我更建议用下面这个口径算账：
每个验收通过结果的成本 =（模型与工具费用 + 人工准备、审核和修正成本 + 维护成本）÷ 验收通过的结果数。
这是一种评估方法，尚不是 Every 公布的经营指标。若暂时无法把人工时间折算成金额，就把时间和费用并列记录。
分母尤其关键。生成了十份材料，不代表完成了十次工作；只有进入下一步、被接受使用的结果，才有资格进入分母。
从这个角度看，AI 带来的一个潜在变化是：草稿供给增加之后，审核会成为限制交付的环节。
如果每份草稿都需要同一位专家逐句修正，团队只是把“从空白开始写”换成了“从大量初稿中挑错”。专家仍然是所有任务必须经过的节点。
共享审核标准的意义，就在于先把重复、明确、容易检查的问题处理掉，让人把精力留给真正有分歧的部分。
10 月 8 日，Every 又发表了将 Agent 基础设施交给 Anthropic 的文章。公开摘要说明，他们从 OpenClaw 转向 Claude Managed Agents，希望把精力放到共享同事产品上。
目前可读内容不足以分析这次迁移的具体性能、费用和完整取舍。但它提供了一个有用的决策问题：哪些维护工作值得自己承担？
对一个小团队来说，如果大量时间都花在修连接、恢复任务和维持执行环境上，就会挤压原本用于理解业务、改进验收方法的时间。托管服务可能帮助转移这些维护工作，也需要另外评估供应商依赖、数据要求和迁移成本。
选择的依据，应当回到团队最需要积累的能力，以及每个可用结果的实际成本。
04 记住审核规则，距离拥有判断力还有多远？
文章开头那个“模拟上司”的案例，正好提醒我们不要把反馈机制想得过于简单。
Mike Taylor 最新文章的公开摘要写道，他模拟的人物知道真人遵循的规则，却不知道何时该打破规则。
后文需要账户，因此我们无法据此复原他的完整测试，也不能把这个表述当作所有模型都成立的实验结论。但它提出的边界，非常值得放进团队工作流的设计里。
因为规则能记录过去的选择，却未必记录了选择背后的全部条件。
比如，下面是一个假设场景：某团队通常要求客户邮件简洁，但一次严重故障需要详细解释时间线、影响和补救措施。如果 Agent 只学会了“邮件要短”，它可能严格遵守格式，却删掉客户最需要的信息。
判断力包含了对条件变化的识别，也包含了对不同目标的权衡。
因此，把专家的经验做成 skill 时，除了记录“通常怎么做”，还应记录“哪些情况需要重新判断”。
一个能够帮助审核的系统，最好能区分三类问题：
可以直接检查的问题。例如链接是否有效、必填字段是否缺失、是否超过已经约定的长度。这些适合自动检查和修正。
需要上下文判断的问题。例如表达是否适合当前客户、这次沟通是否应该增加解释。AI 可以提出建议，但应说明参考了什么，以及哪些信息不足。
涉及承诺和责任的问题。例如是否承诺退款、是否接受合同条款、是否对外公布时间表。预审可以准备材料，授权应由明确的负责人完成。
Every 产品页展示的邮件草稿、支付争议材料等场景，也把“先准备、等待批准”作为流程的一部分。[4] 这些展示不能证明系统绝不会越权，但说明人工批准可以被设计成正常工作的一环。
模拟一个人的审核偏好，不等于获得了这个人的授权。
AI 给出的“他大概会同意”，只能帮助准备决策材料。它不能成为绕过真人审批的理由。
05 国内团队可以先做一个小实验
如果把这组材料放回国内产品、研发或内容团队，我更关心的起点，是找出一项已经反复发生、经常需要同一个人检查的工作。
例如：发布说明初稿、客户会议后的行动项、项目周报整理，或者产品文案预审。选定其中一项，再做下面这个两周实验。
这是一套建议方案，并非我已经在某家公司验证过的成绩。
第一步，记录原流程。
用几次近期任务确定输入、产出和验收人。记录人工准备、审核、返工分别花多久，以及哪些错误反复出现。不要先把“整个运营部门”定义成一个任务。
第二步，把隐含标准写出来。
选几份被接受的结果，也选几份被退回的结果。让负责人解释差别：哪些是通用要求，哪些只适用于当时的客户和情境。由此形成初版方法，并写清需要停下来问人的条件。
第三步，让第二个人独立调用。
把方法放进团队已有的协作入口，可以是企业微信、飞书或现有工单系统。具体平台要另行核验所需集成和权限；这里借用的是工作方式，不是假定国内工具已经具备 Every 的同等能力。
关键测试是：创建者不在旁边指导时，同事能不能拿到可审阅的结果？如果做不到，先记录缺了什么，不要用临时口头解释掩盖问题。
第四步，观察修正能否被下一次使用。
每条审核意见先判断适用范围，再由负责人确认是否进入共享方法。若意见互相冲突，保留不同条件和版本，避免把所有人的偏好堆成一份越来越长的指令。
试验结束时，我会看四件事：
其他同事独立完成任务的比例； 每个通过验收结果需要的人工审核时间； 同类错误在修正后是否再次出现； 维护这套流程花掉的时间，是否抵消了节省。
如果草稿变多了，审核时间却持续上升，就需要缩小范围或重新设计。如果只有最懂 AI 的那个人能用好，也还没有形成团队能力。
反过来，若第二个人能独立调用，重复错误减少，负责人只需要处理少数明确标出的分歧，这项工作才值得继续扩大。
读完 Every 这组文章，我最想继续追踪的，是共享 Agent 能否在创建者不在场、任务出现例外时仍然稳定工作。现有公开材料还不足以回答，也没有跨团队长期数据证明它一定优于个人助手。
但它已经把一个很实际的问题摆到了面前：团队每次纠正 AI 之后，究竟留下了什么？
如果下一次仍然需要同一个人从头解释，能力主要还留在个人身上。如果修正经过确认，变成别人能够调用、能够检查、也知道何时需要请示的方法，团队才开始把个人使用 AI 的经验积累下来。
内容来源：Every《We Were Wrong About Personal Agents》｜https://www.youtube.com/watch?v=_pcy1_jU27k
如果这篇文章对你有所启发，欢迎转发给同样关注产品和出海的朋友。期待和你在评论区和我交流，一起进步。
更多推荐
Google 产品负责人：AI 让产品更容易做了，但真正难的是做出用户愿意留下的产品