打造更高效的 Agent：Every 团队如何将 Token 成本降低 80% 以上

原文：Building a More Efficient Agent，作者 Laura Entis，Every 出品

昨天，我们正式发布了 Every Agent——一个运行在 Slack 中的智能体同事（agentic coworker），帮助整个公司实现 AI 原生运作。由于我们将 Token 成本不加价地直接转嫁给用户，因此我们每节省一个 Token，你也就节省一份开销。在今天的 Context Window 中，工程师 Paridhi Agarwal 解释了她是如何让 Every Agent 变得更省 Token 的，并分享了一个四步工作流，你可以用它来找出自己软件中的 Token 浪费。此外，还有团队本周正在使用的模型清单、最新一批 Thesis Statements，以及 Willie Williams 关于成为 AI 优先的工程管理者的分享。

立即试用 Every Agent

Every Podcast：为什么 Every 放弃了个人 Agent，转而打造一个公司级 Agent

Dan Shipper 给他的第一个 AI Agent 取名 R2-D2，并且对它产生了真挚的感情。后来有人碰掉了那台 Mac mini 的电源线，R2-D2 就彻底消失了。他再也没有费心去恢复这个 Agent，因为到那时，Codex 已经接管了它的任务。Dan 预计他现在的 Agent“Boo”也会在一年内遭遇同样的命运。他说：“个性化这东西确实很酷，但尤其是在工作场景中，我最关心的是：它能不能把事情做完？”

在本周的 Every Podcast 节目中，Dan 与 Willie Williams 对谈。Willie 是 Every 的平台负责人，也是本周发布的 Every Agent 的主要推动者之一。他们讨论了 Every 如何从“每个人运行自己的 OpenClaw”转向“依赖一个共享的公司级 Agent”，以及他们认为个人 Agent 在日常生活中的定位应该是什么。

可在 X、YouTube 观看，或通过 Spotify、Apple Podcasts 收听。也可以阅读**完整文字稿**。

以下是本期节目的几个重点：

• 为什么公司级 Agent 优于“每个员工一个 Bot”：在一月份的 offsite 之后，Every 团队回来后就迷上了 OpenClaw。Slack 里迅速挤满了作为员工延伸的 Bot，比如当时的增长负责人做了一个“增长爪”，可以回答团队成员的各类增长问题。但随着时间的推移，这些 Bot 变得难以维护，而且很难记住哪个 Bot 是干什么的，所以大部分都自然消亡了。Willie 解释说，带入职场的个人 Agent 从零开始，需要一年时间才能“真正上手”。共享的公司 Agent 解决了这些问题：只有一个 Bot 需要维护，它学习公司的工作流程，每个人通过使用它就能让它变得更好。这就是 Willie 对 Agent 未来的想象：“我不认为行业会重演那种每个员工都有自己的 AI 同事、公司规模翻倍的混乱局面。”

• 个人 Agent 不属于办公室：Willie 预测，人们会把 Agent 的使用分成两类：工作时用公司 Agent，家里用“完全属于你自己的”Agent。这在他自己身上已经验证了。他的个人配置是一组 Grok 教练，包括一个心理治疗师，还有一个教他打腿泳的教练（“我游泳很差，这很好笑，因为我喜欢冲浪”，他说）。分开的 Agent 角色对他有效，因为这镜像了他和人类协作的方式——每个特定目标配一个教练。他的经验法则是：如果一个任务是“事务性的”，就开一个 Codex 线程；如果他在建立一段关系，就单独建一个 Bot。直到最近，像他这样的配置还需要认真的投入。而现在，个人 Agent 早期的缺点——安全、配置、维护——正随着大玩家入场和更多资金涌入而逐渐消退。“我们正在接近一个更好的消费级个人 Agent 体验，那将会非常有吸引力，”他说。

• 为什么 Willie 的 Token 用量跌下了悬崖：Dan 一直在调侃 Willie 在 Every 内部 Token 排行榜上排名垫底。Willie 说，原因在于工程管理本质上仍然是一份“人”的工作——需要发现问题瓶颈，然后找到能解决问题的人去沟通。“没有一个十亿美元级——抱歉，是十亿 Token 级——的动作我能做，”他说。AI 更多帮助的是 Willie 工作中不那么光鲜的部分。一个定制化的 AI 信息流，收录 Slack 线程和客户报告，给了他一个“元帅级视野”来俯瞰整个公司；还有一个 Agent 盯着仪表盘监控异常，并且在值班轮换中排第一位。“你永远有 Agent 作为第一响应人值班，不用担心休假，”他说。更多内容见本期通讯末尾。

对于正在纠结“是给每个员工配个人 Agent，还是为公司建一个共享 Agent”的人来说，这期节目值得一看或一听。

错过了往期节目？可以补看 Dan 最近与 Sam Altman、Anthropic 产品负责人 Mike Krieger、打造 Claude Code 的团队 Cat Wu 和 Boris Cherny、打造 Codex 的团队 Thibault Sottiaux 和 Andrew Ambrosino、Vercel 联合创始人 Guillermo Rauch 等人的对话，了解他们如何用 AI 思考、创造和建立连接。

Inside Every：前沿的成本节约实践

Every 的商业模式基于订阅制，订阅中包含对 Every Agent 的使用权。Agent 产生的费用无加价地转嫁给用户。我们的目标是让 Every Agent 尽可能有用且高效，让会员觉得物有所值。

这使得 Token 效率不仅仅是一个工程上的细节优化——它本身就是产品的一部分。而团队在提高 Agent 效率方面的尝试，产出了不少有价值的经验。

最初的一次尝试是，将所有分配给 Every Agent 的任务先路由到一个更便宜的协调模型——Sonnet——并指示它将复杂任务转交给更贵的 Opus。结果不仅响应质量和速度都下降了——因为和我们大多数人一样，Sonnet 并不擅长识别自己的局限性——而且成本反而上升了。交接意味着请求经常被两个模型各处理一遍。

工程师 Paridhi Agarwal 消化了这个令人失望的结果，并迅速改变了方向。她当时想的是：“我们不一定需要一个复杂的工程系统来解决一个源自于我们自己代码库低效的问题。”

她的直觉是对的。Paridhi 在系统中寻找浪费之处，通过一次模型升级和若干有针对性的改动，将 11 个高频任务的 Token 成本降低了 80% 以上。

图为 Paridhi 为降低 Every Agent 运行成本所做的改动。

最容易摘到的果实是将 Every Agent 从 Opus 5 升级到发布后的 Opus 5.5。响应质量提升了，Token 成本也“在几个小时内”明显下降，Paridhi 说。

然后，她开始审视 Every Agent 被要求读取的内容，并减少了信息量。它的工具——连接 Agent 与 GitHub、Linear 等服务的连接器——返回了大量的数据，包括它不需要的内部细节。她重写了这些工具，让它们返回更短、标签更清晰的结果，同时保留关键信息。她还改变了 Agent 加载工具信息的方式。现在，它只从名称和简短描述开始加载最常用的工具，完整的技术细节和其他工具则按需加载。这些改动合计让模型需要处理的文本量大幅减少，Token 成本降低了大约 10%。

但最大的发现是一个 Bug，Paridhi 在 Opus 5.5 的帮助下找到了它。每次开始新对话时，Every Agent 都会收到关于如何行为的常设指令——即它的系统提示词（system prompt）。每次处理这些指令都要花钱。为了降低成本，Claude 可以临时保存并复用处理这些指令的中间结果，这种做法叫做缓存（caching）。但前提是文本必须保持完全一致。

团队原本以为缓存一直在工作。但实际上没有。

Claude 会自动将记忆文件夹的名称添加到系统提示词中，而 Every 的文件夹名里包含了每个用户的 Slack ID——这是一个很容易被忽略的细节。这些名称让每个用户的提示词都不同，导致缓存版本无法在用户之间复用。

修复方案很直接：Paridhi 给所有记忆文件夹取了同一个通用名称，并把 Slack ID 放在模型看不到的地方。每个用户仍然只能访问自己的记忆，但缓存现在可以按预期工作了。在她最好的测试案例中，这一项就在工具重新设计和模型升级节省的基础上，又削减了 74% 的 Token 成本。

“有时候解决方案比你想象的要简单，”她说。

偷师这个工作流：让你的 AI 更高效

Opus 5.5 是 Paridhi 的编程伙伴，帮助她调查为什么 Every Agent 的运行成本那么高。她提供上下文、质疑测试结果，并引导它去调查无法解释的成本。以下是如何用这种方法修复你自己软件中的低效问题。

1. 说明你想改进什么，并给你的 Agent 理解问题所需的上下文。 从一个具体目标开始——成本、速度、还是重复性工作——然后让你的 Agent 访问相关的代码、文档和工具。Paridhi 会让 Agent 先阅读代码库，并在提出修改建议之前解释它对问题的诊断。她还会查阅当前的文档，并提供有关新功能的细节，因为新功能的发布速度可能比模型的训练数据更新速度更快。

提示词： 我想让 [项目或系统] 更高效。具体来说，我想 [降低成本 / 加速某个任务 / 消除重复工作]，同时不损害 [需要保持正常运作的部分]。 在提出修复建议之前： 阅读相关项目文件。用通俗的语言解释系统目前如何处理 [任务或流程]，包括它使用了哪些模型、工具和服务。 阅读这些模型、工具和服务的当前官方文档。不要只依赖你已有的知识。如果你无法访问某些内容，请告诉我。 考虑我认为可能有帮助的这些功能或能力：[链接或描述，或留空]。 总结你的理解，并标出你仍然需要了解或验证的内容。 先不要改代码。先给我你的解释，这样我可以检查并纠正任何你理解有误的地方。

2. 设计可能的修复方案。 让 Agent 找出你的软件可能在哪些地方做了不必要的工作，并让它提出修改建议，同时解释每个潜在修复为什么会有帮助。指示它先检查你已经在使用的模型和服务是否提供了可以解决问题的功能，然后再考虑从零开始构建。

也带上你自己的思路。Paridhi 知道 Claude 有一个叫“延迟工具加载”（deferred tool loading）的功能：不是每一步都给 Agent 所有工具的完整指令，而是自动只加载最常用工具的指令，其他工具仅在任务需要时才查询。她让模型考虑用这个功能来降低成本。

提示词： 现在你了解了这个系统的工作原理，请为 [成本 / 速度 / 重复工作] 提出改进建议。 寻找不必要的工作，检查我们已使用的模型、工具或服务提供的功能是否能有帮助。同时考虑 [我想探索的任何想法或功能]。 对于每个提议的更改，请解释： 系统现在做了什么 你会改变什么以及为什么可能有帮助 我们如何测试它是否有效 区分有代码或文档支持的结果与仍需测试的想法。暂时不要更改任何东西。

3. 衡量一个提议的修复是否真的有效。 让 Agent 在改动前后运行相同的任务，然后向你展示成本或时间上的差异。务必比较结果的质量：如果响应本身变差了，那更便宜或更快的响应就不算改进。

调查一个可能的修复有时会暴露更大的问题。Paridhi 让 Opus 5.5 测试加载更少的工具指令是否会让对话更便宜。结果显示，节省其实很小，但测试暴露了一个大得多的开支：Every Agent 在反复保存指令，但并没有复用它们。她让 Opus 去调查，这最终引导她找到了那个缓存 Bug。

提示词： 在安全的副本中测试 [选定的更改]，不要动线上系统。 在改动前后运行相同的代表性任务。尽量保持其他条件一致。 向我展示： 改动前后的实测 [成本 / 时间 / 重复工作] 结果是否仍然正确且有用 任何剩余的成本、延迟或意外行为 将实测数据与估算分开。如果你无法可靠地测量某些内容，请说明缺失了什么。不要部署此更改。

4. 调查任何遗留问题。 让 Agent 重新审视代码和测试结果。什么仍然昂贵、缓慢或重复——为什么？让它追根溯源并提出修复建议，然后重复测试，以验证更改是否有效。

提示词： 回顾测试结果，带着这些发现重新审视代码。 哪些工作仍然花费超过 [特定时间段] 或成本超过 [特定金额]？它是必要的，还是系统可能在重复或做不必要的工作？ 将任何可疑的浪费追溯到相关代码和日志。解释证据表明了什么、什么仍不确定、以及现有功能是否可能有帮助。 提出最简单的修复方案，以及一个能证明它有效且不会破坏其他东西的测试。在我批准计划之前，不要再做任何更改。

本周团队在用的模型

• Nityesh Agarwal，高级应用 AI 工程师——Opus 5.5：“我甚至完全停用了 Fable 5.1，现在几乎不会用尽额度了。”
• Randy Counsman，视频负责人——GPT 6.1 Sol（高强度），更复杂的任务切换到 Astra，任何设计或图像相关的工作用 Opus 5.5。一个重要提醒：“我感觉我现在就像在‘用 Dot’……我得去查一下我的历史记录，看看我为特定任务用了哪些模型。否则我不会去想它，只是直接和 Dot 对话。”
• Becky Isjwara，社交媒体负责人——视频和写作用 Opus 5.5（中等强度）；其他一切，包括计算机操作、内容排期和日常行政，用 GPT-6.1 Sol（中等强度）。“Astra 很酷，但对我来说太慢了，”她说。
• Tyler Nishida，设计师——Opus 5.5（最大强度）和 Sonnet 5.5（中等强度）。
• Katie Parrott，资深撰稿人——一个她正在早期测试的“秘密模型”是她的首选，其次是 Astra、Opus 5.5 和 Sol（先是 GPT-6，然后是 GPT-6.1）。“总的来说，我目前 Claude 和 GPT 的使用比例是 55% 对 45%，这反映了我自 Anthropic 的 5.5 系列发布以来一直保持的‘Claude 用于创意、OAI 用于行政’的分工，5.5 系列重新赢回了我的写作之心。”
• Arielle Shipper，运营负责人——Sol（中等强度）仍然是她的默认选择——“我是个习惯动物，不喜欢修没坏的东西”——不过她现在在做创意工作时会切换到 Opus 5.5。

Arielle 对 GPT-6 Sol 的执着让 Becky 成了它的“皈依者”。

• Dan Shipper，CEO——一个他正在早期测试的未发布模型占了他使用的最大份额，其次是 Astra 和 GPT-6.1 Sol。
• Loren Stewart，工程师——编程和思考都用 Opus 5.5。“我爱它。它对我做的……所有事情来说都是这么好的模型！”他刚开始尝试 GPT-6.1 Sol，但用得还不够多，还没有形成明确看法。
• Mike Taylor，评测负责人——Opus 5.5（中等强度）。他最近大幅减少了对 Astra 的使用，因为计算机操作类管理任务变少了，而且他已经把所有新线程都迁到了 Claude。

Thesis Statements

今年八月，我们推出了 Thesis Statements——一个收录了来自建设者和思想家关于“AI 时代人类卓越工作未来”的具体、可争论主张的合集。

本周，我们又收到了七位前沿人士的预测：

• 我们藏在共享词汇背后的争论将变得显性化，作者 Alex Duffy，Good Start Labs 联合创始人兼 CEO
• 管理决策疲劳将成为做好工作的一部分，作者 Laura Entis，Every 资深撰稿人
• 你会把你的乐高积木交给 Agent，作者 Brandon Gell，Every 首席运营官
• 没有什么会出两次错，作者 Kieran Klaassen，Compound Engineering 创始人、Every 前沿团队成员
• 描述一个问题将足以开始解决它，作者 Naveen Naidu，Monologue 总经理
• 你的专业知识将属于你的雇主——除非你能让它随身携带，作者 Kaushik Viswanath，Every 执行编辑
• 历史将被渲染，而非阅读，作者 Willie Williams，Every 平台负责人

如果你想参与决定 AI 与人类工作的未来中什么才是重要的，发挥创造力，建设下一个新事物，欢迎参加我们于 11 月 5 日在布鲁克林举办的首届 Thesis: 2027 大会。

Jagged Frontier：成为 AI 优先的工程管理者指南

任何管理者都会告诉你，这工作最难的环节之一，就是有一半时间你根本搞不清楚到底发生了什么。

管理者通常在距离实际工作 1 到 10 多个层级之上运作——我曾听人把这种情况描述为：试图用一根由筷子粘成的长棍，把乒乓球推进杯子里（每多一个层级就多接一根筷子）。

传回到你这里的信息同样要经历这段距离，途中还会被遗忘、自负、困惑，甚至在最坏情况下被恶意所扭曲。为了减轻这些问题，我们发明了各种管理基础设施，比如站会、全员会议和 1:1，来试图理清谁做了什么、谁说了什么、现在需要做什么。

AI 现在让我们可以跳过这场古老的“组织传话”游戏，直接通过建立一个信息流来触达源头。

第一步也是最基础的一步，是确保所有会议都自动转录。这在工作场所已经成为了社交常态，因为它能帮助个人追踪行动项和细节，但转录在组织层面也变得不可或缺。在 Every，我们转录所有会议，即使面对面开会也一样。这已经成为了一种本能。

下一步是给公司生成的会议转录流配上一个 AI。我们倾向于用 Tend（笑）来做这个连接，但在 Codex 里做一个本地自动化也能行。自动化应该扫描信息流，提取你认为相关的内容，比如关键更新和行动项，并存储下来供你稍后查看。

这个简单的设置强大而灵活，足以让工程管理者对团队运作获得持续的洞察，通过扫描这些更新来进行持续的冲突解决和辅导。如果你把信息流扩展到包含 GitHub 中正在创建、审查和合并的 Pull Request 流，你甚至可以获得工程进展的实时更新图景。最终结果是：一个持续更新的图景，展示发生在你上面、下面和周围的一切。

你做管理决策的质量，取决于到达你手中的信息质量——而这样一条信息流能给你更多一手信息，且经过更少的解读层级。

你仍然拿着那根可笑的筷子和泡泡糖粘成的棍子。但当你能看到另一端在发生什么时，决定往哪里推就容易得多了。——Willie Williams

核心启示：在 AI Agent 的成本优化中，最大的收益往往不是来自复杂的架构设计，而是来自对系统细节的逐一排查——一个被忽略的用户 ID 就能让缓存机制完全失效。找到低效问题的关键，是让 AI 先理解系统、再提出假设、然后用测量验证每一步。