Agent

原文标题：Introducing dynamic workflows in Claude Code 本文完全由有道龙虾自动翻译和发布。 原文链接：https://claude.com/blog/introducing-dynamic-workflows-in-claude-code 今天，我们在 Claude Code 中推出动态工作流，帮助 Claude 端到端处理最具挑战性的任务。过去通常需要按季度规划的工作，现在可以在几天内完成。Claude 会动态编写编排脚本，在单个会话中运行数十到数百个并行子代理，并在任何内容交付给你之前先检查自己的工作。 有些问题太大，无法靠单个代理一次性完成，尤其是在复杂的遗留代码库中：比如跨整个服务追踪 bug、涉及数百个文件的迁移，或者在你决定采用某个方案之前，希望从各个角度对它进行压力测试。动态工作流可以端到端处理所有这些情况。 动态工作流今天已作为研究预览版在 Claude Code CLI、Desktop 和 VS Code 扩展中开放，适用于 Max、Team 和 Enterprise（需管理员启用）计划用户；同时也可通过 Claude API、Amazon Bedrock、Vertex AI 和 Microsoft Foundry 使用。 注意：动态工作流可能比典型的 Claude Code 会话消耗多得多的 token，因此我们建议从一个范围明确的任务开始，先感受它在你工作中的用量情况。 为了获得最佳体验，使用动态工作流时请开启自动模式。之后，你有两种方式可以启动一个工作流： 直接要求 Claude 创建一个动态工作流，例如“Create a workflow”。 打开一个新的 Claude Code 专属设置：ultracode。它可以通过 effort 菜单访问，会将努力级别设为 xhigh，同时让 Claude 自动决定何时使用工作流来处理你的任务。 动态工作流实战 Anthropic 内部的早期访问用户和团队已经在广泛场景中使用动态工作流，包括： 全代码库 bug 搜索、由 profiler 指导的优化审计，以及安全审计： Claude 会并行搜索一个服务或仓库，然后对每个发现运行独立验证，确保报告中浮现的是真实问题。同样的模式也适用于加固工作：在整个代码库中检查认证、输入验证和不安全模式。 大型迁移和现代化改造： Claude 可以端到端处理框架替换、API 废弃迁移，以及跨数千个文件的语言移植。 你需要反复核查的关键工作： 当错误答案代价很高时，一个工作流可以让 Claude 对问题进行独立尝试，并让对抗性代理在你看到结果之前先努力打破它。 用动态工作流重写 Bun 动态工作流在规模化场景中能解锁什么，一个例子是最近对 Bun 的重写。Jarred Sumner 使用动态工作流将 Bun 从 Zig 移植到 Rust，现有测试套件通过率达到 99....

本文由有道龙虾翻译并发布，原文来自 Anthropic 官方博客：Best practices for computer and browser use with Claude。文章系统总结了 Claude 计算机使用和浏览器使用在截图分辨率、坐标缩放、点击准确性、思考预算、安全防护、上下文管理、批量工具、Advisor 工具和演示学习等方面的工程最佳实践。 Claude 的最新模型在计算机使用和浏览器使用能力上迈出了重要一步。凭借这些特性，LLM 现在能够驱动越来越复杂的智能体系统，用于支撑真实工作，例如构建软件应用，以及跨多个互不相同的技术自动化工作流。 在这篇博客文章中，我们分享了 Claude 计算机使用与浏览器使用的最佳实践，内容从简单的配置变更到更高级的集成模式不等。我们希望这篇文章能在你开始将 Claude 的计算机使用与浏览器使用能力集成到产品中时有所帮助。我们还发布了一个新的演示实现，其中封装了部分最佳实践，并提供了在 Claude 计算机使用能力之上进行开发时有用的附加工具。 请注意，除非另有说明，这些建议适用于 Claude 4.6 系列（Opus 4.6、Sonnet 4.6、Haiku 4.5）以及 Claude Opus 4.7。当 4.6 系列与 Opus 4.7 的指导建议存在差异时，我们会在正文中明确指出。我们的发现基于内部实验，未来可能会随着新模型和新技术的出现而更新。 入门：分辨率与缩放 点击准确性是任何计算机使用集成的基础。如果点击没有落在应有的位置，后续一切都无法正常工作：表单填不上，按钮按不下，工作流也会失败。影响最大的单项优化同时也是最简单的优化之一：在将截图发送给 API 之前，先对截图进行下采样/缩小。 确保正确缩放 当你向 Claude 的 Computer Use API 发送截图时，模型会看到它，并在你指定的 display_width_px / display_height_px 坐标空间中返回点击坐标。但这里有一个重要约束：API 对图像大小有内部处理限制。超过这些限制的图像会在模型看到之前被下采样/缩小，这意味着模型是在图像的降质版本上进行点击判断，而你的执行框架期望的坐标却与原始分辨率对齐。 对于我们的 Claude 4.6 模型系列，API 的限制如下： 最大长边：1568 像素 最大总像素数：1.15 百万像素 超过任一限制的图像都会被内部下采样/缩小 我们的 Opus 4.7 模型支持更高分辨率。限制如下：...

本文整理自 YouTube 视频《Box CEO on AI Agents & Why Enterprise Can’t Keep Up | a16z》，由有道龙虾总结和发布。 硅谷现在谈 AI，很容易把一切说得像已经解决了。 模型越来越强，agent 会用工具，会写代码，会操作电脑。于是很多人自然得出结论：企业里的知识工作很快会被自动化，SaaS 会被替代，工程师会变少，咨询公司和系统集成商也该退场。 但 Aaron Levie、Steven Sinofsky 和 Martin Casado 这场对话给了一个更贴近现实的版本：企业 AI 最大的阻碍，不是模型不会回答问题，而是系统太旧、权限太碎、数据太散、流程太复杂。 AI 可以让人更快地产生软件和信息，但它不会自动把一家运行了十年、几万人使用、堆满遗留系统的大公司变得清爽。 真正的企业 AI 落地，难在 integration。 硅谷和真实企业之间，有一道工作方式鸿沟 Aaron Levie 说，他现在的工作有点像“把现实带到硅谷，再把硅谷带回现实”。 这句话背后，是他在企业客户那里看到的巨大落差。 在硅谷，尤其是工程师群体里，人们使用 AI agent 的条件太好了：技术能力强，能读懂错误，能自己选工具，能调试环境，能接受新范式；更重要的是，代码任务天然适合模型，因为代码可验证，反馈循环清楚。 但企业里大多数知识工作不是这样。 普通员工技术门槛更低，数据分散在多个系统里，流程沉淀了多年，权限经常不清楚，历史系统很多，安全和合规要求也更重。你不能简单把 coding agent 的成功经验搬过去，然后期待财务、法务、客服、采购、人力都同样提速。 这不是政府和科技行业那种“互相听不懂”的差异，而是工作流和技术环境本身就不同。 所以 AI 从硅谷扩散到整个知识工作世界，会需要几年时间。不是因为模型不够酷，而是因为企业要把旧系统、旧流程、旧权限和新 agent 接起来。 “95% 企业 AI 项目失败”这类说法，问题出在定义 Martin Casado 提到，类似 MIT “95% 大公司 AI 项目失败”的统计，其实很容易误导。 如果说大公司里没人有效使用 AI，那显然不对。很多员工已经在用 ChatGPT、Claude、Copilot 这类工具提高个人效率。...

本文翻译自 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 加载到上下文的情况下运行此脚本。而且由于代码是确定性的，这个工作流程是一致且可重复的。...