工程师们有时候会在下班前把任务交给 Agent，第二天早上打开电脑，积压的工单处理完了，bug 已经修好了。这不是未来，这是 Anthropic 内部现在的日常工作方式。

说这话的人叫 Jess Yan——Anthropic 的 Claude Managed Agents 产品负责人，拥有深厚的工程与产品背景。她的产品，是 Anthropic 押注 Agent 时代的核心基础设施之一。

这期播客由 Peter Yang 对 Jess 进行专访，全程约 40 分钟，内容涵盖：Agent 究竟是什么、Claude Managed Agents 的产品演示、Anthropic 内部如何用 Agent 工作、如何向企业落地推广，以及 Agent 正在重塑整个垂直 SaaS 赛道的深远影响。

本文编译自 YouTube 播客专访《Inside Anthropic's Bet on Claude Agents that Work While You Sleep | Jess Yan》。以下是完整编译。

在 Jess 看来，今天的人们谈到"Agent"时，其实说的已经不是同一件事了。

早期的 Agent 几乎就是提示词循环——你给它一个问题，它给你一个答案，再来一轮，再来一轮。这种方式让它能完成一些简单的对话式任务，但本质上仍然是同步的、脆弱的，每一步都依赖上一步的成功。

现在，Agent 已经进化成了另一种存在：自主的、能长期运行的、可以访问第三方系统和内部数据库的行动者。它不只是回答问题，而是能接入你的代码仓库、CRM 系统、Slack 频道，做真正的工作。

这种进化带来了新的问题：权限管理、可观测性、如何在任务跑偏时把它拉回来。这就是为什么"harness（执行框架）"变得那么重要。

什么是 harness？ Jess 解释说，harness 是围绕模型搭建的核心脚手架——它告诉 Agent 什么时候该调用工具、什么时候该读取记忆、什么时候该暂停等待人的指令，而不是继续往下走。它是让 Agent 从"吐 token"变成"真正干活"的那层基础结构。

她还提出了一个有意思的观点：模型和 harness 是高度绑定的。你无法脱离 harness 去评估一个模型的真实能力，因为所有实际部署都是通过某个 harness 进行的。Anthropic 在测试 Claude 时，也一定是结合自家的 harness 来跑评估的——Claude Code、Claude Claude（内部产品）以及第三方的参照实现。这种绑定在某种程度上是不可避免的，也是合理的。

Claude Managed Agents 是 Anthropic 给开发者提供的一套预构建执行框架，核心目标只有一个：让搭建一个 Agent 的投入产出比极其高。

Jess 在现场演示了一个数据分析 Agent——它面向一家虚构的杂货店（Just in Time），被喂入了数百万行的销售数据，自主跑完了三份分析报告：商品购买模式分析、购物者行为热图，以及一个预测模型——基于顾客属性预测他是否会回头消费。这一切，仅靠一次初始提示和标准 Python 包，在几分钟内完成。

她讲解了一个 Managed Agent 的基本构成：

• 模型选择：决定 Agent 的智能层

• 系统提示：定义行为边界和通用能力

• 工具集：平台内置的文件系统、代码执行等能力，以及通过 MCP 接入的第三方系统

• 权限设置：每个工具调用可以设为"自动执行"或"需要人工确认"

• 技能（Skills）：可选模块，赋予 Agent 额外的专项能力

与自己从零搭提示词循环相比，Managed Agents 的优势在于：它是云托管的、异步的、能自我恢复的。当一个原始的提示词循环出错，你只能重头来过；而 Managed Agent 能感知到输出跑偏了，主动调整策略，继续朝目标推进——同时把过程信息推送给你。

控制台里还内置了一个"调试 Agent"，在 Agent 跑完整个任务后，可以对全部历史 trace 做分析，找出哪些地方还可以优化。

Jess 聊起自己的日常工作方式，有几个细节相当具体。

她最感受深刻的一点是：代码库访问权限彻底改变了她作为产品经理的能力边界。过去，了解某个功能的实现细节，需要找工程师。现在，她可以直接查 PR、追踪哪些变更已经合并、哪些已经部署。不需要问别人，自己就能进入技术细节。这让她在客户沟通和内部讨论中都能以"真正懂产品的人"的身份出现，而不是一个传话筒。

她的日程表里，有一些定期自动运行的任务——比如每周汇总内部工程活动的摘要——但更多是按需触发的深度挖掘：准备客户 pitch 前、进行 RFP 安全审核时、需要快速掌握某个新技术领域时。

一个有趣的细节：她和团队会在决策会议上直接召唤 Claude 做"中立裁判"。Anthropic 内部有一个"API Review Claude"，当团队在某个 API 设计上陷入僵局、谁也说服不了谁时，就让 Claude 来指出谁的偏见影响了判断。这并不是开玩笑——是真实的内部工作流。

她也坦承：有时候和 Claude 交流的频次比和同事更高。尤其在进入一个陌生领域时，她会花大量时间和 Claude 做"思维梳理"，理清一个棘手的概念，带着清晰的观点和基础研究去参加团队会议。这样的对话质量，和"等着别人给我讲清楚"完全不同。

主持人问到了 Agent 落地时一个很现实的痛点：怎么知道 Agent 没有跑偏？怎么做 eval？

Jess 的答案是：这确实是今天构建 Agent 最难的部分，并且整个评估体系正在随着任务复杂度的提升而进化。

传统的评估方式——给定输入，检查输出——在简单任务上仍然有效。但随着 Agent 的任务越来越长、越来越动态，新的评估范式也在涌现：

• 多轮交互回放（Replay eval）

  ：重放一段复杂的多步对话，评估 Agent 在不同情景下的表现

• A/B 测试

  ：用相同的交互序列跑不同版本的 Agent，比较响应差异

• 内置自评（Built-in eval loop）

  ：让 Agent 自己知道"什么是好输出"，在 session 内部就完成自我打分和迭代

Claude Managed Agents 正在推动第三种方向。Jess 举了一个例子：她设定了一个"准确率达 90%"的目标，让 Agent 自主迭代直到命中这个分数——这个循环在 Agent 内部发生，不需要人工介入每一轮。

她也区分了几种 eval 类型：二元通过/失败（pass/fail）、基于 LLM 打分的评分制（LLM as judge），以及"特定行为触发检测"——比如确保技能在正确的时机被调用，而不是等着用户手动触发。

对于刚开始落地的团队，她的建议是：先做 Vibe Testing，再上 Eval。把 Agent 放到真实用户（哪怕只是 beta 用户）手里，感受真实反馈，比在内部跑一堆 eval 更有价值。当你开始无法从 vibe 中聚合出量化信号时，再引入系统性评估。

Jess 对企业部署 Agent 的观察，集中在一个常见误区上：很多企业一上来就想自动化一个横跨 20 个团队、耗时几个季度的复杂流程。方向没错，但起点错了。

她的建议是倒过来想：先赋能个人，再扩展到团队。

当一个个体员工——无论是工程师、产品经理还是销售——突然拥有了以前需要多个人协作才能完成的能力，这件事本身就足够有价值。不需要一上来就颠覆整个合规审批流程；先让每个人都感觉到"自己就是一支小团队"，这种原子级的赋能，才是企业 Agent 普及的真正起点。

对于如何在公司内部推广，她给了一个实用建议：提供模板，允许自由迭代。不要让员工面对空白页不知从何下手，也不要锁死他们的发挥空间。模板解决的是"开始的恐惧"，自由迭代解决的是"用起来的乐趣"。

她自己也身体力行——她会在几周内为某个临时任务快速搭一个 Agent，用完就丢，不追求产品化的精致。一个能帮她自动处理 4000 条等待名单（过滤无效条目、评估转化概率、每日按优先级推送邀请）的 Agent，可能只花她半小时搭建，但节省的是接下来几周的人工。

采访的最后，Jess 谈到了一个宏观趋势：模型越来越强，通用域的能力差距在收窄，真正的价值差异正在向"极致垂直"转移。

以前，一个"通用会计 Agent"可能已经足够。但当底层模型的推理能力越来越强，"广度知识"变成了基础设施，差异化就必须靠"深度定制"来体现——不是一个面向所有企业的会计 Agent，而是一个专门服务于"独立太阳能创业者"的会计 Agent。

这个逻辑延伸出来，意味着：谁能把 Agent 放进用户真正工作的地方，谁就赢了。不是一个独立的 Web 网站，不是一个让用户填表的门户，而是嵌入到 Claude Code、嵌入到 Slack、嵌入到聊天界面里——在用户已有的工作流里就位，而不是要求用户迁移到一个新平台上。

Jess 给出了她对未来 3-6 个月的判断：工作效率的天花板，将不再取决于个人能力，而取决于你能同时委托出去多少。我们正在从"我能做多少"过渡到"我能管理多少个 Agent 同时做"。

（来源：硅星GenAI）