你能将多少任务委托给智能代理？（7分钟阅读）

# 你能放心交给智能体多少工作？ 来源：https://newsletter.posthog.com/p/agent-autonomy 人们越来越信任智能体在没有监督的情况下完成更多工作，但如何判断何时可以信任它们？ 有人认为答案取决于模型有多强——也就是说，当模型变得更好时，就可以信任它们做更多事。但仅仅因为模型变聪明了就信任你的智能体，就像因为换了辆更好的车就不系安全带。 真正的答案与模型无关，而完全取决于**任务**本身。你需要建立一套关于何时委托以及委托多少的心理模型，然后根据实际情况调整。 以下是一份最大化智能体自治程度的简单指南，让你既能快速交付，又**不会**搞砸。 你首先需要问自己两个问题： 要安全地自主运行，智能体在出错时需要立即得到反馈。对于大多数带有确定性检查（如单元测试和集成测试）的代码来说，这是可行的。但主观性任务，比如为清晰起见重命名一个参数，如果没有人的品味和判断力就会困难得多。 就像传统软件工程一样，如果你想信任一个智能体在没有监督的情况下运行，你需要为最坏情况准备一个可靠的“Ctrl+Z”。正因如此，我们的 PR 审批智能体 [StampHog](http://posthog.com/newsletter/code-review-tips?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy#3-add-a-pr-auto-stamper) 会将包含禁用关键词的任何内容转交给人类处理。 综合这两个因素¹(https://newsletter.posthog.com/p/agent-autonomy#footnote-1)，任何任务都会指向以下四个级别之一： - **第 0 级：智能体作为助手。**适用于难以检查且难以撤销的任务。处理棘手且敏感的代码时必需。 - **第 1 级：人在回路中。**适用于难以检查但容易撤销的任务。通常需要主观评估时使用。 - **第 2 级：委托给智能体。**适用于容易检查但难以撤销的任务。目前大多数开发工作的默认上限。 - **第 3 级：自动驾驶模式。**适用于容易检查且容易撤销的任务。一切都在朝这个方向发展。 你可以将这四级映射到一个非常简单的决策树，适用于任何任务： [](https://substackcdn.com/image/fetch/$s_!HnV9!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb8188004-4403-4b09-87ed-29462aed3aa1_1600x828.png) 这可以帮助你决定将多少工作委托给你的智能体，但你仍然可以设计你的流程，以提升特定任务的自治程度。 *当工作**难以检查**且**撤销成本高*** 这是智能体自治程度最低的级别。想想向 ChatGPT 寻求建议，或者在 Cursor 中使用自动补全，就像 2024 年美好的旧时光一样。 但这并不意味着它不好；在处理敏感代码表面上的棘手问题时，这种模式是理想之选。 例如，当 [Dylan](https://posthog.com/community/profiles/30455?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy) 去年更新我们的功能开关引擎以支持通用属性定位时，他必须迁移一个间接嵌入 PostHog 每个功能开关中的假设。 这对于智能体来说很难用确定性方式检查，因为无法通过 `grep` 来搜索。同时，这次更新的影响范围巨大，因为它涉及实时的客户开关、API 响应形状以及理由评分函数。 **将任务拆解。**小部分工作能让委托是否安全变得一目了然。Dylan 将不太关键的工作（比如将新的定位逻辑传播到我们的 JavaScript、PHP、Ruby 和 Flutter SDK）交给智能体，而风险较高的核心迁移则亲自动手。 *当工作**难以检查**且**撤销成本低*** 这种智能体自治级别常见于需要主观评估的任务，因为目前（至少现在）很难教会智能体品味和判断力。 [](https://substackcdn.com/image/fetch/$s_!0Qs7!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F66fe69c5-2059-4181-b41d-01ff90a0037a_1600x710.png) 人在回路中的任务被认为撤销成本低，因为代码保持在草稿模式，在人工验证之前不会合并。撤销只是意味着开始另一次迭代。 [这段代码可读性重构](https://github.com/PostHog/posthog/pull/35127) 由 [Thomas](https://posthog.com/community/profiles/30210?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy) 主要手动完成，但它是一个很好的例子，说明智能体不知道如何评分。它只是几行代码，使人类更容易理解——添加注释、分组操作、将字符串替换为枚举——并且没有引入任何破坏性变更。 - **使用 LLM 作为裁判。**这是目前大多数人构建智能代码审查系统的方式。随着模型不断改进，更多需要人类判断的任务可以用 [LLM 来检查](https://posthog.com/blog/testing-ai-agents?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy#non-deterministic-evaluators)。 - **定义有范围、可衡量的目标。**成功指标或契约可以作为主观评估的代理。例如，你可以指示一个系统对落地页文案进行实验，直到某个变体达到 3% 的转化率。 - **编写自定义技能。** (http://posthog.com/newsletter/agent-first-product-engineering?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy#4-writing-skills-is-a-human-skill) 这有助于智能体稳定地产生符合你标准、规范和品味的成果，所需引导更少。例如，许多开发者编写自定义的代码审查技能，以遵循团队特定的标准。 *当工作**容易检查**且**撤销成本高*** [](https://substackcdn.com/image/fetch/$s_!W_Ho!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec383514-0369-4f64-b8da-a116f938c2f3_1600x710.png) 这是目前大多数开发者任务所处的级别。智能体编写可以用确定性测试的代码，但最终的合并操作需要通过最后的安全检查。 当 [Robbie](https://posthog.com/community/profiles/29292?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy) 用 Rust 从头重写我们的 [SQL 解析器](https://posthog.com/blog/sql-parser?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy) 时，他几乎没怎么看代码，因为他有一个机器“神谕”来检查工作。但由于解析器触及 PostHog 的每个查询，智能体的工作被多个安全检查所门控：生产环境的影子模式，然后是分阶段切换。 **用代码实施策略和安全护栏。**大多数人默认将第 2 级任务放在人工（也就是自己）后面门控，但这种习惯会让你成为自己的瓶颈。相反，将尽可能多的安全护栏直接编码到你的流程中，比如默认进行试运行、限制凭据范围、以及通过[功能开关](https://posthog.com/feature-flags?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy)来发布变更。 *当工作**容易检查**且**撤销成本低*** 目前这个类别中的任务并不多——只有较小的任务，如依赖升级、代码风格修复、为现有代码增加测试覆盖率。但这个类别正在快速增长，特别是随着长时间运行的智能体、目标驱动循环以及更复杂的编排。 在 PostHog，我们全力致力于让 [自动驾驶](http://posthog.com/docs/self-driving?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy) 模式对构建者成为现实。例如，上个月我们推出了 [Scouts](https://posthog.com/blog/what-is-a-scout?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy)——这些智能体按计划运行，调查产品数据中的信号，并根据发现的结果起草 PR。 - **训练领域特定模型。**下一波工具的大部分内容将围绕改进 LLM 目前难以完成的验证任务。一个显而易见的路径是训练特定用途的模型，使其了解在特定领域什么算是“好”，这也是我们在 PostHog [训练自己的 AI 模型](http://posthog.com/blog/training-ai-models?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy) 的原因。 - **构建专家级上下文库。**智能体自治程度不足往往只是因为上下文缺失。我们从 [为 PostHog Wizard 工程化上下文层](http://posthog.com/newsletter/context-engineering?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy) 的亲身体验中学到，用结构化的新鲜知识弥补这一差距，是构建可靠智能体最高杠杆率的事情之一。 - **为 Scouts 设计清晰的信号。**长时间运行智能体的瓶颈在于它们是否知道什么时候有值得做的工作，以及如何区分有效的[信号](http://posthog.com/docs/self-driving/signals?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy) 和随机噪声。 *文字由 [Jina Yoon](https://x.com/jinayoon_) 撰写，她以第 0 级状态编写这些通讯。* - **技术客户成功经理 - 美洲地区 (https://posthog.com/careers/technical-customer-success-manager-americas?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy)** - **技术客户成功经理 - EMEA 地区 (https://posthog.com/careers/technical-customer-success-manager-emea?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy)** - **BDR 团队主管 (https://posthog.com/careers/bdr-team-lead?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy)** - **营收运营经理（销售方向） (https://posthog.com/careers/revenue-ops-manager-(sales-focused)?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy)** - **智能体自治级别 (https://addyo.substack.com/p/agentic-autonomy-levels) – Addy Osmani** - **重新定位 PostHog (https://posthog.com/blog/repositioning-posthog?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy) – Charles Cook** - **Cerebras 如何构建其企业知识库 (https://www.cerebras.ai/blog/how-we-built-our-knowledge-base) – Isaac Tai, Daniel Kim, Mike Gao** - **什么是上下文仓库？ (https://posthog.com/blog/what-is-a-context-warehouse?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=agent-autonomy) – Lizzie Epton** - **Claude 5 模型上下文工程的新规则 (https://x.com/trq212/status/2080710971228918066) – Thariq Shihipar**