Agent

本文翻译自 Anthropic 官方技术博客：Demystifying evals for AI agents。 主要观点 有效的评估（Evals）是团队自信地发布 AI Agent 的基础。与单轮对话的 LLM 不同，Agent 涉及多轮交互、工具调用和状态修改，这使得它们更难评估。缺乏评估会导致团队陷入被动的“打地鼠”模式，仅能在生产环境中发现问题。相反，建立评估体系能让问题在早期显现，量化改进效果，并促进产品与研究团队的协作。 一个完整的评估体系包括任务（Task）、评分器（Grader）、评估工具（Harness）和数据集（Suite）。针对不同类型的 Agent（如代码、对话、研究、计算机操作），需要采用不同的评估策略。评分器通常结合了基于代码的确定性检查、基于模型的灵活评分（LLM-as-judge）以及人工审核，以平衡速度、成本和准确性。 构建评估体系不需要一开始就追求完美。文章提出了一个实用的路线图：从少量的现实失败案例开始，逐步建立无歧义的任务集，设计稳健的测试环境和评分逻辑，并长期维护。重要的是要结合自动化评估、生产监控、A/B 测试和人工审查，形成一个多层次的质量保障网络（类似瑞士奶酪模型），以全面理解 Agent 的性能。 关键细节 核心定义与组件 构建 Agent 评估时涉及以下关键概念： Task (任务)：具有定义输入和成功标准的单个测试用例。 Trial (尝试)：对任务的一次执行，通常需要多次运行以应对非确定性。 Grader (评分器)：对 Agent 表现进行打分的逻辑，可包含多个断言。 Transcript (实录)：完整的交互记录，包括输出、工具调用和推理过程。 Outcome (结果)：试验结束时环境的最终状态（例如数据库中是否存在预定记录）。 不同类型 Agent 的评估策略 Coding Agents：通常使用确定性评分器。例如 SWE-bench Verified 通过运行单元测试来验证代码修复是否成功。 Conversational Agents：侧重于交互质量和任务完成度。常使用 LLM 模拟用户进行多轮对话，并结合状态检查（如工单是否解决）和语气评分。 Research Agents：评估较为主观。策略包括检查内容的依据性（Groundedness）、覆盖率（Coverage）和来源质量。 Computer Use Agents：在沙盒环境中运行，通过检查截图或 DOM 状态来验证结果。例如 WebArena 和 OSWorld。 评分器类型 基于代码 (Code-based)：如字符串匹配、静态分析。优点是快速、便宜、客观；缺点是缺乏灵活性。 基于模型 (Model-based)：如 LLM 评分量表。优点是灵活、能捕捉细微差别；缺点是成本较高，需人工校准。 人工评分 (Human)：专家审查。优点是质量金标准；缺点是昂贵且慢，通常用于校准模型评分器。 处理非确定性与指标 由于 Agent 行为在不同运行间存在差异，文章提出了两个关键指标：...

2025 年 3 月 5 日，一家在武汉的创业公司蝴蝶效应发布一款 Agent 产品： Manus，该产品能够调度不同的工具解决复杂问题，其在 GAIA 等基准测试中表现出 SOTA 的性能。该产品一经发布便引发国内外的关注和讨论，火爆程度堪比 DeepSeek R1 的盛况。 2025 年 12 月 17 日，Manus 宣布年度经常性收入（ARR）已突破 1 亿美元。消耗总 token 量超过 147万亿 token，创建了超过 8000 万台虚拟计算机。 2025 年 12 月 30 日，Meta 以 20 亿美元收购 Manus 的公司蝴蝶效应。收购完成后，蝴蝶效应公司将保持独立运作，创始人肖弘出任 Meta 副总裁。 配图来自于2025 年 7 月 Manus 团队对谈 YouTube 联合创始人陈士骏。左起依次为：季逸超（Manus 联合创始人、首席科学家）、肖弘（Manus 创始人兼 CEO）、陈士骏、张涛（Manus 联合创始人，产品负责人） 本文整理自 Manus 被 Meta 收购前对外接受的最后一次专访，张小珺对谈季逸超（Peak）：Manus’ Final Interview Before the Acquisition: Oh, the Surreal Odyssey of 2025。这篇访谈长达 3 小时 31 分钟，季逸超的分享畅汗淋漓，信息量超大，虽然本文能让你快速了解其中的核心输出和认知，但我还是建议大家去看原视频，开 1....

本文整理自 Anthropic 的工程师 Barry 和 Mahesh 在 AI Engineer 做的关于 Skills 的分享：Don’t Build Agents, Build Skills Instead。 Anthropic 这帮工程师真的非常高产，继创造了 MCP 协议、Claude Code 编码 Agent 后，又创造了 Skills。他们的每一次创新都是源于实际工程开发中的真实需求，比如： MCP 协议的提出是因为解决模型与异构数据源（如本地文件、SaaS工具）连接的碎片化与标准化难题； Claude Code 创造是因为突破对话框的限制，让 AI 直接深入本地开发环境，实现从“阅读代码”到“执行构建”的自主闭环。 而 Skills 的创造是因为 将高频、复杂的任务逻辑封装为可复用的标准化模块，让 Agent 拥有长期的“肌肉记忆”，避免在重复任务中反复进行低效的 Prompt 引导。 以下是本次分享的核心内容，由我和 Gemini 3 Pro 共同整理而成。 代码就是这一层通用的接口 以前我们有个误区，觉得不同领域的 Agent 应该长得完全不一样。做金融的 Agent 和写代码的 Agent，肯定需要完全不同的工具和脚手架，甚至得为每个用例单独造一个 Agent。 但后来我们发布了 Claude Code（我们的第一个编程 Agent），搞着搞着发现：原来底下那个通用的 Agent 其实比我们想象的要强大得多。 代码不仅仅是一个使用场景，它其实是连接数字世界的通用接口。 想象一下生成一份财务报告：模型调用 API 拉数据、在文件系统里整理、用 Python 分析、最后输出格式化文件。这一整套流程，其实只需要极薄的一层脚手架（Bash 和文件系统）就能搞定。 智商 300 的天才 vs....

本文由 Anthropic 工程师 Justin Young 撰写：Effective harnesses for long-running agents。本文探讨了随着 AI Agent能力增强，在处理跨越数小时或数天的复杂任务（如软件工程）时面临的核心挑战：如何在多个有限的上下文窗口（context windows）之间保持工作的连贯性。作者指出，仅靠上下文压缩不足以解决问题，Agent 容易出现试图一次性完成任务（one-shotting）或过早宣布任务完成的失败模式。 为了解决上述问题，作者提出了一套基于 Claude Agent SDK 的双重解决方案： 初始化Agent （Initializer agent）：负责在首次运行时设置环境和规划任务。 编码Agent （Coding agent）：负责在后续会话中进行增量开发，并为下一次会话留下清晰的记录。 这一方案通过结构化的环境设置、详细的功能列表和严格的增量工作流，确保Agent 能够像人类工程师轮班一样，在没有先前记忆的情况下高效接手工作。 关键细节 核心挑战与失败模式 上下文限制：Agent 在离散的会话中工作，新会话开始时没有之前的记忆。 常见错误：在使用 Opus 4.5 等前沿模型时，若仅给出高层级提示，Agent 倾向于试图一次性构建整个应用，导致上下文耗尽、功能半途而废且缺乏文档；或者在仅完成部分功能后误判项目已完成。 解决方案的具体实施 环境初始化：Initializer agent 会创建关键的基础设施，包括： init.sh 脚本：用于启动开发环境。 claude-progress.txt 文件：记录Agent 的操作日志。 初始的 git 提交：建立版本控制基础。 功能列表（Feature List）：创建一个包含详细需求的 JSON 文件（例如 claude.ai 克隆项目包含 200 多个功能点）。选择 JSON 而非 Markdown 是为了防止模型意外覆盖文件结构。 增量工作流与状态管理 快速上手（Getting up to speed）：Coding agent 在每个会话开始时执行标准化步骤： 运行 pwd 确认工作目录。 读取 git 日志和进度文件以了解最近的工作。 读取功能列表，选择优先级最高且未完成的功能。 运行 init....

本文由 Anthropic 工程师 Ken Aizawa 所写：Writing effective tools for agents — with agents。其中介绍了一系列为 AI 代理（agents）构建高效工具的最佳实践和核心原则。为非确定性的 AI 代理设计工具与为传统的确定性软件系统编写函数或 API 有着根本性的不同，需要采取一种以代理为中心、由评估驱动的迭代开发方法。 关键细节 1. 构建和优化工具的流程 文章提出了一个与 AI 代理协作、以评估为驱动的迭代流程： 构建原型： 快速搭建工具原型，并利用 Claude Code 等 AI 代理辅助编写。可以通过本地 MCP (Model Context Protocol) 服务器或桌面扩展进行测试。 运行综合评估： 生成任务： 与 AI 代理协作，生成大量源于真实世界、具有足够复杂度的评估任务。强任务可能需要多次、甚至数十次工具调用。 运行评估： 通过直接调用 LLM API，在简单的代理循环中运行评估。建议让代理输出推理过程（CoT）以更好地理解其行为。 分析结果： 代理是发现问题的合作伙伴。通过分析其推理过程、原始交互记录以及调用指标（如冗余调用、错误率），可以发现工具的不足之处。 与代理协作改进： 将评估结果和记录直接输入给 Claude Code，让它分析问题并重构优化工具代码和描述，从而形成一个持续改进的闭环。 2. 编写高效工具的核心原则 选择合适的工具： 质量优于数量。避免简单地将每个 API 端点都包装成一个工具。 应构建少数几个针对高影响力工作流程的、经过深思熟虑的工具。例如，用一个 schedule_event 工具整合查找空闲时间和创建会议等多个步骤。 命名空间（Namespacing）： 当工具数量增多时，使用共同的前缀（如 asana_projects_search）对相关工具进行分组，可以帮助代理在不同工具间做出正确选择，避免混淆。 返回有意义的上下文： 工具返回的数据应优先考虑上下文相关性，而非技术细节。使用自然语言名称（name）代替晦涩的标识符（uuid）。 提供多种响应格式（如 concise 和 detailed），让代理可以根据需要选择信息的详细程度，从而控制上下文的消耗。 优化令牌（Token）效率：...

文本由 Anthropic 工程师由 Erik Schluntz 和 Barry Zhang 撰写：Building effective agents，文中探讨了构建高效 AI 代理（Agent）的最佳实践。 最成功的 AI 代理系统并非建立在复杂的框架之上，而是采用简单、可组合的模式。开发者应从最简单的方案（如优化单个 LLM 调用）开始，仅在确实需要时才引入更复杂的代理系统。诸如 LangGraph 等框架虽然可以简化初始开发，但也可能引入不必要的抽象层，使调试变得困难。建议开发者直接使用 LLM API，并确保理解所使用框架的底层逻辑。 代理系统的核心在于 LLM 与工具的交互。因此，投入精力设计一个清晰、易于使用的“代理-计算机接口” (ACI) 至关重要，这包括编写详尽的工具文档和进行充分的测试。文章提出了一系列从简单到复杂的构建模式，从基础的“增强型 LLM”到自主代理，开发者可以根据具体需求组合和定制这些模式。 关键细节 代理系统的类型 工作流 (Workflows)：通过预定义的代码路径来编排 LLM 和工具，具有较高的可预测性。 代理 (Agents)：LLM 能够动态地指导自己的流程和工具使用，更加灵活，适用于无法预知步骤的开放式问题。 核心构建模式 基础模块：增强型 LLM 这是所有代理系统的基础，即一个集成了检索、工具和记忆等增强功能的 LLM。 工作流：提示链 (Prompt Chaining) 将一个任务分解为一系列连续的步骤，每一步的 LLM 调用处理上一步的输出。适用于可清晰分解为固定子任务的场景。 工作流：路由 (Routing) 对输入进行分类，并将其引导至专门的下游任务或模型。例如，将简单的客户问题路由到成本更低的 Claude Haiku 4.5 模型。 工作流：并行化 (Parallelization) 让 LLM 同时处理一个任务的不同部分。具体可分为： 分片 (Sectioning)：将任务分解为独立的子任务并行运行。 投票 (Voting)：多次运行同一个任务以获得多样化的输出或更可靠的结果。 工作流：协调器-工作者 (Orchestrator-workers) 由一个中央 LLM（协调器）动态分解任务，并将其分配给多个 LLM（工作者）执行。适用于子任务无法预先确定的复杂场景，如编码。 工作流：评估器-优化器 (Evaluator-optimizer) 一个 LLM 负责生成响应，另一个 LLM 在循环中提供评估和反馈，以迭代方式改进输出质量。 自主代理 (Autonomous Agents) 适用场景：用于解决难以预测所需步骤的开放式问题。代理能够独立规划和执行，并通过与环境（如工具调用结果）的交互来评估进展。 注意事项：自主代理的成本更高，且存在错误累积的风险。因此，必须在沙盒环境中进行广泛测试，并设置适当的护栏（如最大迭代次数）。 实践应用领域 客户支持：代理可以通过集成工具来查询客户数据、处理退款等，将对话与实际操作相结合。 编码代理：代理可以根据需求描述自主修改多个代码文件，并通过自动化测试来验证解决方案的正确性，例如在 SWE-bench 基准测试中的应用。 原文：构建高效的智能体 发布于 2024年12月19日...

Anthropic 最近虽然口碑差，但人才密度还是高，继 MCP 之后他们又新推出来 Agent Skills，这个思路非常好，既给了 Agent 确定性，也给了其几乎无限的上下文，顺便帮你省了钱。也算是和 MCP 互补，一个连接外部系统，一个连接本地脚本和文档。 Agent Skills 的核心思想也很简单，就是通过提供一个由Skill、脚本和资源组成的结构化文件夹，将领域专家的知识打包在这些文件夹中，让 Agent 能够动态加载这些“Skills”。 Skill 的构成与工作原理大概是下面这样： 一个 Agent Skill 本质上就是一个包含 SKILL.md 文件的目录，该文件有一定的规范，比如必须以包含元数据（如name和description）的 YAML 前置内容开头等等。 Agent Skills 通过分层加载信息来高效管理上下文窗口： 第一层: Agent 在启动时仅加载所有已安装 Skill 的name 和 description，以便知道何时使用某个 Skill。 第二层: 当 Agent 认为某个 Skill 与当前任务相关时，它会读取该技能的 SKILL.md 文件的完整内容。 第三层及以上: 对于更复杂的任务，技能可以包含额外的辅助文件（如 reference.md 或脚本）。Agent 只在需要时才会读取这些文件，这个意思基本就是 Skills 可以包含几乎无限的上下文信息。 Skill 中可以包含预先编写好的固定的代码（如 Python 脚本）。Agent 可以像使用工具一样执行这些代码，以处理传统代码更擅长的确定性或高效率的任务，而不需要把代码本身加载到上下文中。 这个的好处很明显，把AI 生成的质量不稳定的代码变成稳定可控的代码，既大大缩小上下文，也节省了很多成本。 这篇文章中也举了两个 Skills 的典型应用例子： 通过AI 生成的代码来对列表进行排序，远比简单地运行一个排序算法要昂贵得多。除了效率问题，许多应用还需要只有代码才能提供的确定性可靠性。 PDF Skills 包含一个预先编写的 Python 脚本，用于读取 PDF 并提取所有表单字段。Claude 可以在不将脚本或 PDF 加载到上下文的情况下运行此脚本。而且由于代码是确定性的，这个工作流程是一致且可重复的。...

2025 年 7 月 17日，OpenAI 发布 ChatGPT Agent 功能，这是一个统一的 Agent 系统，它能利用自己的虚拟计算机和多种工具，处理从数据分析、网络研究到任务执行的复杂工作流程。该功能融合了 OpenAI 年初发布的两个 Agent 功能： Operator 的网页交互能力和 DeepResearch 的深度分析能力，并引入了新工具，使其能够在一个统一的界面中完成更广泛、更复杂的任务。 关键细节 核心功能与工作方式 任务执行能力： 用户可以要求 ChatGPT agent 执行诸如“分析竞争对手并创建幻灯片”、“规划并预订旅行”或“根据最新新闻为我简报即将到来的客户会议”等复杂任务。 工具套件： 它配备了一套综合工具，包括可视化浏览器、文本浏览器、终端和 API 访问权限，使其能够智能地选择最高效的方式来完成任务。 协同工作流程： ChatGPT agent 支持与用户进行迭代式协作。它会在需要时主动向用户请求更多信息，用户也可以随时介入以澄清指令或调整任务方向。 性能与基准测试 业界顶尖表现： 在多个衡量真实世界任务能力的基准测试中，ChatGPT agent 的表现均达到了新的业界顶尖（SOTA）水平，显著优于之前的模型，在某些任务上甚至超过了人类专家。 具体数据： 在 Humanity’s Last Exam（专家级问题测试）中，得分达到 41.6%。 在 DSBench（数据科学任务）上，准确率达到 89.9%，显著超越人类表现。 在 BrowseComp（网络浏览信息定位）中，准确率达到 68.9%，比 deep research 高出 17.4 个百分点。 风险与安全措施 应对新风险： 该功能引入了新的风险，如处理敏感数据和防范“提示词注入”（prompt injection）攻击。 多层安全防护： 用户确认： 在进行购买等有实际影响的操作前，必须获得用户的明确许可。 主动监督： 发送邮件等关键任务需要用户在“观察模式”（Watch Mode）下进行监督。 风险规避： 模型被训练以主动拒绝银行转账等高风险请求。 生物安全： 由于能力增强，该模型被置于最高级别的生物安全防护之下。 可用性与当前限制 推出范围： 该功能已开始向 Pro、Plus 和 Team 用户推出，Pro 用户每月有 400 条消息的使用额度。其他付费用户每月有 40 条消息，额外用量可通过灵活的基于积分的选项获得。 功能局限： ChatGPT agent 仍处于早期阶段，有时可能会出错。 幻灯片生成功能尚处于 beta 测试阶段，生成的内容在格式和美观度上可能较为基础。 原文：推出 ChatGPT 智能体：连接研究与行动 ChatGPT 现已具备思考和行动的能力，能主动从一系列智能体技能中进行选择，使用其自己的计算机为您完成任务。...

本文是 LangChain CEO Harrison Chase 在 OpenAI 发布了一份关于构建智能体 ( agents ) 的指南之后写的一篇文章，这篇文章主要用于指出 OpenAI 的智能体指南中的一些误导性观点，并给出了自己的一些看法。 定义区分： 工作流 (Workflows)：通过预定义代码路径编排 LLM 和工具，可预测性高。 代理 (Agents)：LLM 动态指导自身流程和工具使用，灵活性高。作者更倾向于 Anthropic 对此的精确技术定义。 代理失败原因：LLM 表现不佳通常源于上下文问题，如：系统提示不完整、用户输入模糊、工具描述/访问不当、未传入正确上下文、工具响应格式不佳等。 LangGraph 特点： 提供底层编排能力（节点 Nodes 和边 Edges）。 支持声明式（图结构）和命令式（节点/边内部逻辑）编程。 内置持久化层，支持容错、短期/长期记忆。 支持“人在回路”（human-in-the-loop）和“人监控回路”（human-on-the-loop）模式。 内置流式处理（streaming）支持。 与 LangSmith 集成，提供调试、评估和可观测性。 框架价值：除了代理抽象，好的框架还应提供：短期/长期记忆管理、人机交互支持、流式输出、调试/可观测性、容错机制等。这些价值对工作流和代理都适用。 对 OpenAI 指南的批评：作者认为 OpenAI 的指南： 错误地将 LangGraph 等声明式方法描绘为繁琐且不灵活。 混淆了“声明式 vs 命令式”与“工作流 vs 代理”以及“抽象”的概念。 声称 Agents SDK 等“非声明式”（实为抽象）方法更灵活、“代码优先”，作者认为这与事实相反。 未能抓住构建可靠代理系统的核心挑战（上下文控制）和框架应提供的核心价值（可靠的编排层）。 多代理系统：关键在于代理间的通信机制，工作流常用于组织多个代理的协作。 框架对比：作者提供了一个电子表格链接，用于比较 LangGraph, Agents SDK, CrewAI, AutoGen 等多种框架在不同维度（如编排 vs 抽象、特性支持）上的表现。 原文：如何看待 AI 智能体框架 总结：...

本文的核心观点是，真正的 生成式 AI LLM 智能体 (agents) 正在到来，它们与目前常见的基于工作流的系统有着本质的区别。这些新型智能体能够进行规划、记忆，并有效地执行多步骤、长期的任务。与预定义规则和提示的工作流系统不同，真正的 LLM 智能体能够动态地指导自身流程和工具使用，从而克服了传统方法在可扩展性和长期效能方面的局限性，并有望在各个领域带来颠覆性变革。文章强调，要实现真正的 LLM 智能体，需要采用 强化学习 (RL) 与推理 (Reasoning) 相结合的方法，并克服数据和计算方面的挑战，以推动这项技术的民主化发展。 LLM 智能体的定义与兴起： 文章指出，OpenAI 在 2025 年 1 月发布的 DeepResearch 以及 Claude Sonnet 3.7 是真正的 LLM 智能体的早期例证。Anthropic 将 LLM 智能体定义为能够动态控制自身流程和工具使用的系统，这与通过预定义代码路径编排 LLM 和工具的工作流系统形成对比。 工作流系统的局限性： 文章批评了当前许多 “智能体” 系统，如 Manus AI，实际上是工作流系统，它们在规划、记忆和长期行动方面存在根本性缺陷，例如无法有效规划搜索策略、难以维持超过 5-10 分钟的任务、以及长期行动中容易累积错误。 “苦涩的教训” (Bitter Lesson)： 文章引用了 Richard Sutton 的 “苦涩的教训”，指出在 AI 智能体中硬编码知识和规则虽然短期内有效，但长期来看会阻碍进步。真正的突破来自于扩展计算规模，并基于搜索和学习的方法。这表明，依赖预定义提示和规则的工作流系统注定会遇到瓶颈。 RL + Reasoning 是制胜之道： 文章强调，真正的 LLM 智能体需要通过 强化学习 (RL) 进行训练，并结合推理能力。训练过程涉及生成草稿、评估结果 (通过验证器 verifiers) 以及迭代优化。DeepSeek 的 GRPO 算法和 vllm 技术被认为是实现高效 RL 训练的关键。 数据和计算的挑战与解决方案： 训练 LLM 智能体，特别是对于复杂任务如搜索，需要大量的行动序列数据。由于缺乏公开的 agentic 数据，文章提出了通过模拟 (emulation) 和合成数据生成来解决数据瓶颈的思路。例如，可以创建网络搜索的模拟环境，并利用 Common Crawl 等数据集进行训练。 LLM 智能体的应用前景： 文章展望了 LLM 智能体在搜索之外的应用，例如网络工程 (自动生成设备配置、分析网络拓扑) 和金融领域 (数据标准转换)。这些应用场景都超越了传统工作流系统的能力，需要智能体具备自主规划和动态决策的能力。 技术民主化的必要性： 文章最后指出，目前 LLM 智能体技术主要掌握在少数大型实验室手中，为了促进技术发展和应用普及，需要推动 LLM 智能体训练和部署的民主化，例如开放验证器、 GRPO 训练样本以及复杂的合成管线和模拟器。 原文：真正的 LLM Agents 即将到来 实际的大语言模型 AI 智能体 (LLM Agent) 即将到来。它们将被训练 现在“智能体”这个词随处可见。然而，在大语言模型 (LLM) 驱动的智能体研究领域，一项最重要的研究进展却几乎没有引起人们的注意。...