写在前面欢迎大家关注Rocky的知乎Rocky DingAIGC算法工程师/开发工程师面试面经秘籍分享WeThinkIn/Interview-for-Algorithm-Engineer欢迎大家StarAIGC时代的《三年面试五年模拟》AI算法工程师/开发工程师求职面试秘籍独家资源【三年面试五年模拟】AI算法工程师面试秘籍Rocky最新撰写AI AgentAI智能体的深入浅出全维度解析文章深入浅出完整解析AI AgentAI智能体的核心基础知识AIGC算法岗/开发岗面试面经交流社群涵盖AI Agent、AIGC图像创作、AI视频、LLM大模型、AI多模态、数字人、传统深度学习、具身智能等AIGC面试干货资源欢迎大家加入https://t.zsxq.com/33pJ0大家好我是Rocky。核心导读这篇 Anthropic 工程博客真正值得讨论的并不是它又列了一组 Agent 工作流模式而是它把 2024 年以来 AI Agent 产业落地里最容易被忽略的一件事讲清楚了有效的 Agent 系统首先不是“让模型更自由”而是把模型的自由放进一个可观测、可验证、可回滚的任务闭环里。Rocky认为这篇文章的价值在于它非常克制。它没有把 Agent 神化成“自主智能体即将替代一切”也没有把框架包装成护城河而是把 Agent 拆回到几个朴素的工程问题什么时候只需要一次 LLM 调用什么时候需要固定工作流什么时候才值得让模型动态规划工具使用工具接口应该如何设计才能让模型少犯错这背后其实是 AI Agent 走向生产环境时的一个关键转向上半场大家关心“模型能不能做事”下半场真正重要的是“系统能不能稳定地把事做完”。模型能力是起点任务边界、反馈信号、工具设计、评测体系和人工监督才是 Agent 从 Demo 走向产品的工程地基。问题背景作者到底想解决什么Agent 这个词在过去一年被用得太宽。有些人说 Agent是指一个能长期自主运行、自己规划、自己调用工具的系统有些人说 Agent只是指几个提示词串起来、再加一点工具调用的自动化流程。Anthropic 在文章里先做了一个很重要的切分把这一整类系统统称为 agentic systems但在架构上区分 workflow 和 agent。Workflow 是 LLM 和工具沿着预定义代码路径被编排。也就是说系统知道大概要走哪些步骤模型只是步骤里的智能处理单元。Agent 则不同它让 LLM 动态决定自己的过程和工具使用方式模型不只是执行节点而是在一定边界内控制任务推进。这个区分非常关键。因为很多团队做 Agent 失败不是模型不够强而是一开始就把“工作流问题”误判成“自主 Agent 问题”。如果任务路径本来清楚硬要让模型自由规划只会增加成本、延迟和不可控性如果任务路径本来不可预测却强行写死流程系统又会在真实场景里失去弹性。Anthropic 的中心建议很直接先找最简单可行解只有当复杂度能被实际效果证明时才增加复杂度。很多应用甚至不需要 Agent优化单次 LLM 调用加上检索和上下文示例已经足够。这句话听起来保守但它反而是 Agent 工程化最重要的现实主义。AI 产品真正难的部分往往发生在第一次演示成功之后而不是 Demo 跑通当天。第一次能跑通只能说明模型有潜力第十次、第一百次、在边界条件下还能稳定完成才说明系统有产品价值。核心思路用一句主线串起来这篇文章可以用一句话概括从增强型 LLM 出发用最少的抽象和最清晰的反馈把任务逐级拆成 Prompt chaining、Routing、Parallelization、Orchestrator-workers、Evaluator-optimizer最后才进入真正开放式 Agent。这里的顺序不是简单的模式清单而是一条复杂度阶梯。越往后模型获得的自主权越大系统能处理的不确定性越强但成本、延迟、调试难度和错误累积风险也越高。Rocky认为这也是很多 Agent 团队需要补的一课Agent 不是“框架越复杂越先进”而是“任务不确定性越高才越需要更强的动态决策能力”。架构复杂度应该来自问题本身而不是来自对 Agent 概念的想象。方法展开沿着原文逻辑拆解1. 增强型 LLMAgent 系统的最小原子Anthropic 把增强型 LLM 作为所有 agentic systems 的基础单元。所谓增强不是简单把模型换成更大参数而是让 LLM 接入 retrieval、tools、memory 等外部能力。模型可以自己生成搜索查询、选择合适工具、决定保留哪些信息。这张图真正说明的是现代 LLM 应用的基本单元已经不再是“prompt - answer”这么简单而是“模型 上下文 工具 记忆”的组合。模型负责语言理解、推理和决策检索负责补充外部知识工具负责改变外部状态记忆负责跨轮次延续任务上下文。但这里也有一个容易被忽略的细节能力接入不是越多越好。工具越多模型越需要理解每个工具的适用边界记忆越复杂越容易引入过期信息或错误状态检索越开放越需要判断来源质量。增强型 LLM 的核心不是堆能力而是让模型能以低认知负担使用这些能力。这也是 Model Context Protocol 这类协议出现的意义。它试图把工具与上下文接入标准化让模型可以通过更清晰的接口访问外部世界。Rocky认为从产业角度看MCP 这类协议的长期价值不只是“接更多工具”而是把 Agent 的外部行动能力变成可复用基础设施。2. Prompt chaining把大问题拆成更容易被模型做对的小问题Prompt chaining 是最朴素也最常用的 workflow把任务拆成一串步骤每一步 LLM 处理上一步的输出中间可以加程序化检查确保过程没有跑偏。这个模式的本质是用延迟换准确率。一个复杂任务直接交给模型模型需要同时完成理解、规划、生成、检查等多个动作注意力会被拉得很散。把它拆成多个清晰步骤后每次调用只处理一个更窄的问题系统也能在中间节点加 gate 做质量控制。原文给的例子包括先生成营销文案再翻译成另一种语言先写文档大纲检查大纲是否符合要求再基于大纲写正文。这些例子都符合一个共同特征任务可以被干净拆分成固定子任务。Rocky在实际使用 LLM 做内容、代码和资料整理时也有类似体感。很多人觉得模型“不稳定”其实是把太多目标塞进一次调用里既要它查资料又要它判断价值还要它写成公众号风格还要它生成标题和摘要。更稳的方式往往不是换一个更玄的 Agent 框架而是把任务拆开先收集后判断再组织最后润色。Prompt chaining 的边界也很清楚如果任务路径固定它很好用如果任务下一步取决于输入本身、外部结果或动态环境它就会变得僵硬。也就是说它适合“可拆解”但不适合“不可预知”。3. Routing不要让一个提示词同时讨好所有场景Routing 的思路是先分类输入再把不同类型输入送到不同后续流程、提示词或工具链里。它解决的是 LLM 产品里一个非常现实的问题如果用一个通用提示词处理所有请求优化某一类输入时很可能伤害另一类输入。客户服务是最典型的例子。普通咨询、退款请求、技术支持、投诉升级表面上都叫“客服问题”但所需信息、风险级别、工具权限和回复风格完全不同。如果全部塞给同一个 Agent系统很容易在低风险问题上过度谨慎在高风险问题上又不够严格。Routing 的价值在于 separation of concerns也就是把不同问题分给不同专家路径处理。它可以是 LLM 分类也可以是传统分类模型或规则。关键不是分类技术本身而是类别边界必须足够稳定分类结果必须足够可靠。这里还有一个很重要的成本视角。原文提到可以把简单常见问题路由给更便宜的小模型把困难异常问题路由给更强模型。这是 Agent 产品化必须面对的经济问题如果每一个请求都调用最强模型、多轮工具链和复杂 Agent单次体验可能很好但商业闭环未必成立。Rocky认为很多 AI 应用最终拼的不是“能不能调用最强模型”而是“能不能把强模型用在真正需要它的地方”。Routing 本质上是把模型能力变成资源调度问题。4. Parallelization并行不是为了炫技而是为了速度和置信度Parallelization 让多个 LLM 调用同时处理任务再由程序聚合结果。Anthropic 把它分成两类Sectioning 和 Voting。前者把任务拆成独立子任务并行运行后者让多个模型调用从不同角度尝试同一任务提升结果置信度。Sectioning 适合那些天然可以拆开的任务。例如一个模型生成主回复另一个模型同时做安全审查或者自动评测时让不同模型调用分别评价准确性、完整性、风格一致性和风险。这样比让一个模型在同一次调用里兼顾所有目标更稳因为每个调用的注意力更聚焦。Voting 则适合高风险判断。例如代码漏洞审查可以让多个提示词从不同漏洞类型切入内容安全审核可以让多个判断维度分别给出结论再用阈值控制误杀和漏判。这类模式的本质不是“多跑几次就更智能”而是用系统结构弥补单次模型输出的不确定性。LLM 输出天然带有概率性尤其在模糊、开放、高风险任务里一次输出往往不该被直接当成最终事实。并行调用加聚合可以把模型的不稳定性转化成可管理的统计信号。但 Parallelization 也不是免费午餐。它会增加调用成本也会引入结果聚合问题。不同模型意见冲突时谁来裁决多维度评估之间如何加权这些都需要具体业务定义。没有清晰评价标准的并行只会生成更多看似丰富、实则难以决策的文本。5. Orchestrator-workers当子任务无法预先写死时让模型来拆任务Orchestrator-workers 比普通并行更进一步。它不是提前写好所有子任务而是让一个中心 LLM 根据输入动态拆解任务再把子任务分派给多个 worker LLM最后综合结果。这个模式特别适合代码修改和复杂搜索。比如一个 coding agent 接到任务后可能需要改几个文件、每个文件改哪里、是否需要新增测试这些都很难提前写死。搜索任务也类似系统不知道哪些信息源最相关也不知道中间发现会不会改变后续搜索方向。它和 Parallelization 长得很像但关键差异在于Parallelization 的子任务通常是预定义的Orchestrator-workers 的子任务是动态生成的。也就是说前者解决“可并行的固定任务”后者解决“需要动态拆解的复杂任务”。Rocky认为这是 Agent 从 workflow 走向更高阶系统能力的一个临界点。因为从这里开始模型不再只是执行步骤而开始参与任务结构设计。它需要判断问题空间、拆分工作量、分配资源、综合结果。这个能力很强但风险也变大拆错任务会导致后续所有 worker 都在错误方向上努力。所以 Orchestrator 的质量决定整个系统上限。它不只是一个“调度器”更像一个项目经理。它要知道任务目标也要知道哪些子任务可以独立推进哪些子任务存在依赖关系哪些结果需要回到主线重新评估。Agent 产品要做得好不能只盯着模型生成能力还要设计好这个调度层的反馈与约束。6. Evaluator-optimizer让模型在明确评价标准下自我迭代Evaluator-optimizer 是一个生成器和一个评估器之间的闭环一个 LLM 生成结果另一个 LLM 根据标准给出反馈生成器再修改直到达到目标或触发停止条件。这个模式真正有效有两个前提。第一任务有明确评价标准第二人类给出的反馈确实能改进模型结果而且模型也能生成类似质量的反馈。文学翻译、复杂搜索、长文润色、代码审查都可能符合这个条件。这里最值得注意的是“可评价性”。很多团队喜欢做自我反思、自我批判、多轮改写但如果没有可验证标准循环很容易变成语言上的自我安慰。模型会不断说“我改进了逻辑、增强了严谨性”但实际结果未必更好。Rocky认为Evaluator-optimizer 的核心不是“让模型多想几轮”而是把人类原本隐性的质量标准显性化。比如一篇技术文章评价标准可以包括是否有中心判断、是否区分事实和解释、是否解释机制、是否指出边界、是否有读者可执行的启发。如果这些标准不清楚所谓 optimizer 只是让文本变长。这个模式也解释了为什么 AI 写作、AI 编程和 AI 搜索正在从“单次生成”走向“生成-评估-修正”的工作流。未来真正有价值的 AI 产品不只是给用户一个答案而是能稳定穿过一个质量收敛过程。7. Agents当路径无法预设时才进入真正自主循环在 Anthropic 的定义里Agent 是 LLM 根据环境反馈循环使用工具、推进任务、必要时请求人类帮助的系统。它从用户命令或交互开始明确任务后进行规划和执行执行过程中通过工具结果、代码运行、环境状态等 ground truth 判断进展遇到阻塞点时暂停请求人类反馈最后在任务完成或达到停止条件时结束。这张图是整篇文章的核心。它提醒我们Agent 的关键不是“自主”两个字而是“环境反馈”。没有反馈模型只是在想象中推进有了反馈系统才能判断自己是否真的改变了外部世界。Coding agent 为什么相对容易落地因为代码世界天然有反馈测试能否通过类型检查是否报错文件是否修改成功程序是否运行。客服 Agent 为什么也适合因为工单是否解决、退款是否成功、用户是否确认都可以成为闭环信号。反过来如果一个任务没有清晰成功标准没有可靠环境反馈没有合理工具权限也没有人类监督 checkpoint那么把它做成 Agent 反而危险。自主性会放大错误长链路会累积偏差工具权限会把语言错误变成真实世界错误。Anthropic 明确提醒Agent 适合开放式问题步骤数量难以预测固定路径无法硬编码且你对模型的决策能力有一定信任。但它也带来更高成本和错误累积风险因此需要沙盒测试和护栏。Rocky认为这里有一个很重要的产品判断Agent 不是“越自主越高级”而是“在可信环境里把可验证任务规模化”。真正成熟的 Agent 产品应该让模型在需要自由的地方自由在需要控制的地方被约束。8. 两个最有落地价值的场景客服与编程Anthropic 在附录里强调了两个实践场景Customer support 和 Coding agents。它们看似差异很大一个面向业务服务一个面向软件开发但底层逻辑相同都有对话入口、外部工具、明确目标、反馈循环和人工监督。客服场景里Agent 可以通过工具访问客户数据、订单历史、知识库并执行退款、更新工单等动作。更重要的是客服问题的成功标准相对明确用户定义的问题是否被解决。一些公司甚至采用按成功解决计费的商业模式这说明 Agent 的价值可以和业务结果绑定。编程场景里Agent 的优势更明显。代码问题结构化结果可以通过自动化测试验证模型可以根据测试结果迭代修复。SWE-bench 这类任务之所以成为 Agent 能力评估的重要基准也是因为它把“会写代码”进一步推进到“能根据真实 issue 修改多文件项目并用测试反馈收敛”。但 Anthropic 也没有把 coding agent 说成完全自动化。自动化测试可以验证功能但人类 review 仍然重要因为系统要求、架构一致性、长期可维护性不一定能被单个测试集完全覆盖。这也是 Rocky对 Agent 落地最核心的判断Agent 最先改变的不是所有工作而是那些结果可验证、过程可反馈、工具可封装、人类可审查的工作。这类任务会率先被规模化而那些目标模糊、评价主观、外部状态复杂且风险高的任务会更长时间停留在人机协同阶段。实验与证据结果能支撑到什么程度这篇文章不是一篇学术论文没有给出系统 benchmark、消融实验或统一指标。它的证据主要来自 Anthropic 与多个行业客户合作构建 LLM agents 的工程经验以及 Anthropic 自身在 coding agent、computer use 等系统中的实践。因此我们不能把它当成“某个模式一定优于另一个模式”的严格实验证明。它更像是一份从生产经验中提炼出来的工程设计指南。它能支撑的结论是在当前 LLM 能力和产品约束下简单、可组合、可观测的系统更容易成功复杂框架和高自主 Agent 只有在任务不确定性真正需要时才值得引入。从证据强度看它最可靠的部分是模式归纳和工程经验这些模式确实覆盖了当前很多 Agent 产品的常见结构。它较弱的部分是缺少量化比较比如不同模式在成本、延迟、准确率、故障率上的具体差异文章没有展开。但这并不削弱它的实践价值。恰恰相反Agent 行业现在最缺的不是更多概念而是更清晰的工程判断。很多团队的问题不是不知道有 prompt chaining、routing、parallelization而是不知道什么时候该用什么时候不该用以及如何证明复杂度真的带来了收益。这篇工作的边界与可复现性这篇文章有几个边界需要特别说明。第一它主要讨论通用 Agent 工程模式而不是某个具体框架的完整实现。读者可以从中获得架构判断但不能直接得到一套可运行系统。第二它没有把安全、权限、审计、合规展开到企业级深度。对于客服、金融、医疗、法律、企业内部操作等场景Agent 的工具权限和审计日志会成为核心问题。一个 Agent 能调用工具不等于它应该拥有所有工具权限。第三它没有提供严格的成本模型。实际生产中复杂 agentic systems 往往会显著增加 token 成本、工具调用成本、延迟成本和调试成本。什么时候值得多花这些成本需要结合业务转化、人工节省、错误代价来算。第四它默认读者已经具备一定 LLM 工程能力。比如如何写提示词、如何设计评测集、如何记录中间状态、如何处理工具异常这些都需要团队自己补齐。因此这篇文章最适合被当作 Agent 架构的“决策地图”而不是“施工图纸”。它告诉你复杂度阶梯长什么样但每一级怎么在自己的业务里落地还要回到任务、数据、工具、评测和业务闭环。如果继续研究/落地应该关注什么如果把这篇文章往后推进Rocky认为有五个方向最值得关注。第一Agent 复杂度评估。团队需要建立一套判断标准单次 LLM 调用、固定 workflow、动态 orchestrator、开放 Agent到底应该选择哪一级这个标准应该同时考虑任务不确定性、错误代价、反馈可得性、工具风险、成本预算和用户容忍度。第二Agent eval。传统模型评测只看答案对不对但 Agent 评测要看过程是否可控、工具调用是否合理、错误恢复是否有效、最终任务是否真实完成。未来 Agent 产品的护城河很大一部分会来自任务级评测集和运行日志分析。第三Tool / ACI 设计。Anthropic 在附录里提到工具定义应该像 prompt 一样被认真工程化。好的工具接口要让模型容易用对参数命名清晰格式接近模型训练中常见的文本形态避免让模型做大量格式开销。Rocky认为未来会出现一种新的工程能力不是 HCI而是 ACI也就是 Agent-computer interface 设计能力。第四权限和沙盒。Agent 一旦能操作外部系统就必须有权限分层、沙盒验证、回滚机制和人工确认。特别是涉及资金、账户、生产环境、用户数据的场景没有这些机制的 Agent 只能是演示不该进生产。第五商业闭环。Agent 最有价值的地方不是“看起来像人”而是能否把可衡量任务结果规模化。客服按成功解决计费、编程按 issue 修复和测试通过衡量都是更健康的方向。真正能穿越周期的 Agent 产品不会只卖“智能感”而会卖可验证的结果。术语与概念速查概念本质适用场景主要风险增强型 LLMLLM 接入检索、工具、记忆等外部能力大多数 LLM 应用的基础单元工具过多、接口不清、上下文污染Workflow沿预定义代码路径编排 LLM 与工具路径清晰、步骤稳定的任务对动态问题不够灵活AgentLLM 动态规划过程和工具使用路径不可预测、需要多步自主探索的任务成本高、错误累积、权限风险Prompt chaining顺序拆解任务每步处理上一步输出可固定拆分的复杂生成任务延迟增加流程僵硬Routing先分类再进入专门路径多类型输入、不同风险等级、模型成本调度分类错误会把任务送错路径Parallelization多个 LLM 调用并行处理并聚合可并行子任务、多视角审核、高风险判断成本上升、结果冲突难聚合Orchestrator-workers中心 LLM 动态拆解任务并分派 worker代码修改、复杂搜索、多源分析Orchestrator 拆解错误会放大全局偏差Evaluator-optimizer生成器与评估器形成迭代闭环有明确评价标准的写作、搜索、翻译、代码任务没有评价标准时容易空转ACIAgent-computer interface面向模型的工具接口设计所有工具型 Agent工具描述不清会导致模型误用拓展思考值得继续扩展研究与思考的创新点1. Agent 的护城河会从框架迁移到任务闭环早期 Agent 项目喜欢比谁的框架复杂、节点多、链路长。但从 Anthropic 的经验看真正有效的系统反而常常使用简单模式。Rocky认为这意味着 Agent 创业和产品竞争的护城河不会长期停留在框架层。框架会开源模式会被复制模型能力会被 API 化。真正难复制的是任务闭环你是否理解用户真实工作流是否知道哪些步骤可以自动化哪些必须人类确认哪些反馈能衡量任务完成哪些工具权限可以安全开放。工具不是护城河判断才是护城河。Agent 时代尤其如此。2. Agent 工程师会从 prompt writer 变成系统设计者如果只是写几个提示词Agent 很难稳定进生产。一个合格的 Agent 工程师需要懂任务拆解、工具接口、评测体系、日志分析、权限控制、产品交互和业务指标。这会改变 AI 岗位结构。过去很多人把 LLM 应用开发理解成 prompt engineering但真正进入生产环境后prompt 只是其中一环。更重要的是全链路交付能力从问题定义到数据接入从工具封装到异常处理从模型选择到成本控制从评测集到上线监控。AI不会尊重一个人熬了多少年只会放大一个人真正能创造多少价值。Agent 工程正在把这个趋势进一步放大。3. “自主性”不是目标“可控地完成任务”才是目标很多关于 Agent 的讨论把自主性当作终点。但 Anthropic 这篇文章提醒我们自主性只是手段。Agent 不是为了看起来像一个独立员工而是为了在某些任务中减少人工步骤、扩大执行规模、提升结果质量。如果固定 workflow 能完成任务就不需要 Agent如果一次 LLM 调用能完成任务就不需要 workflow如果检索加示例能解决问题就不需要多轮工具调用。真正成熟的 AI 产品往往不是把技术上限全部展示给用户而是把刚好够用的复杂度隐藏在稳定体验后面。4. ACI 会成为 Agent 产品的关键基础设施Anthropic 在附录里讲了一个很细但很重要的例子在 SWE-bench Agent 中他们发现模型在使用相对路径工具时容易出错于是把工具改成强制使用绝对路径模型使用就稳定了。这个例子很小却非常本质。人类工程师可以理解相对路径、当前目录、上下文切换模型在长链路执行中却可能因为一个路径状态判断错误导致任务失败。解决方案不是责怪模型“不够聪明”而是设计更不容易出错的工具接口。这就是 ACI 的价值。未来很多 Agent 系统的差距不在模型 API 本身而在工具是否为模型友好地设计。一个好的工具定义本质上是在替模型减少无意义认知负担让它把能力用在真正的任务推理上。总结Agent 不是更复杂的聊天机器人而是可验证任务系统读完 Anthropic 这篇文章Rocky最大的感受是Agent 行业正在从概念热闹走向工程克制。有效 Agent 的核心不是堆框架、堆工具、堆自主循环而是从任务本身出发选择刚好够用的复杂度。能用单次调用解决就不要硬上 workflow能用固定 workflow 解决就不要硬上 Agent必须让模型动态规划时就一定要给它清晰工具、环境反馈、停止条件、评测标准和人工监督。Agent 的本质不是“模型像人一样行动”而是“模型在可验证环境里完成任务”。这句话可能没有“AI 员工全面来临”那么刺激但它更接近产业真实。因为所有能穿越周期的技术最后都要从惊艳回到可靠从概念回到结果从自由回到约束。对开发者来说真正该学习的不是某个 Agent 框架的语法而是任务拆解和系统评测能力。对产品经理来说真正该判断的不是能不能做 Agent而是这个任务是否值得 Agent 化。对创业者和投资人来说真正该看的不是 Demo 多像人而是它有没有明确反馈闭环、可持续成本结构和真实客户结果。工具红利会退潮认知红利会上升。Agent 时代真正有价值的依然是那些能把模型能力、工程系统、产品场景和商业闭环连在一起的人。参考来源Anthropic Engineering, “Building effective agents”, published Dec 19, 2024.推荐阅读1. 深入浅出完整解析AI AgentAI智能体的核心基础知识2025年可以说是AI Agent全面落地应用的元年因此Rocky在持续撰写对AI Agent的全维度解析文章深入浅出完整解析AI AgentAI智能体的核心基础知识2. 深入浅出完整解析扩散模型DDPM、DDIM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识和Rocky一起学习探究扩散模型的本质原理与和核心基础知识同时不断跟进扩散模型的最新发展。Rocky在本文中对扩散模型的本质做了全面系统的梳理与讲解深入浅出完整解析扩散模型DDPM、DDIM、SDE、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识3. 深入浅出完整解析FLUX.2、Seedream即梦、Z-image、GLM-Image核心基础知识https://zhuanlan.zhihu.com/p/19751746910491895624. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识5. 深入浅出完整解析DeepSeek系列核心基础知识深入浅出完整解析DeepSeek系列核心基础知识6、Sora等AI视频大模型的核心原理核心基础知识网络结构经典应用场景从0到1搭建使用AI视频大模型从0到1训练自己的AI视频大模型AI视频大模型性能测评AI视频领域未来发展等全维度解析文章正式发布码字不易欢迎大家多多点赞Sora等AI视频大模型文章地址深入浅出完整解析Sora、Wan2.1、AnimateDiff、CogVideoX等AI视频大模型核心基础知识7、Stable Diffusion 3和FLUX.1核心原理核心基础知识网络结构从0到1搭建使用Stable Diffusion 3和FLUX.1进行AI绘画从0到1上手使用Stable Diffusion 3和FLUX.1训练自己的AI绘画模型Stable Diffusion 3和FLUX.1性能优化等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion 3和FLUX.1文章地址深入浅出完整解析Stable Diffusion 3SD 3和FLUX.1系列核心基础知识8、Stable Diffusion XL核心基础知识网络结构从0到1搭建使用Stable Diffusion XL进行AI绘画从0到1上手使用Stable Diffusion XL训练自己的AI绘画模型AI绘画领域的未来发展等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion XL文章地址深入浅出完整解析Stable Diffusion XLSDXL核心基础知识9、Stable Diffusion 1.x-2.x核心原理核心基础知识网络结构经典应用场景从0到1搭建使用Stable Diffusion进行AI绘画从0到1上手使用Stable Diffusion训练自己的AI绘画模型Stable Diffusion性能优化等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion文章地址深入浅出完整解析Stable DiffusionSD核心基础知识10、ControlNet核心基础知识核心网络结构从0到1使用ControlNet进行AI绘画从0到1训练自己的ControlNet模型从0到1上手构建ControlNet商业变现应用等全维度解析文章正式发布码字不易欢迎大家多多点赞ControlNet文章地址深入浅出完整解析ControlNet核心基础知识11、LoRA系列模型核心原理核心基础知识从0到1使用LoRA模型进行AI绘画从0到1上手训练自己的LoRA模型LoRA变体模型介绍优质LoRA推荐等全维度解析文章正式发布码字不易欢迎大家多多点赞LoRA文章地址深入浅出完整解析LoRALow-Rank Adaptation模型核心基础知识12、深入浅出完整解析AIGC时代Transformer核心基础知识在AIGC时代中Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向成为AI技术架构大一统与多模态整合的关键核心基座大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析Transformer文章地址深入浅出完整解析AIGC时代Transformer核心基础知识13、最全面的AIGC面经《手把手教你成为AIGC算法工程师斩获AIGC算法offer2024年版》文章正式发布码字不易欢迎大家多多点赞AIGC面经文章地址手把手教你成为AIGC算法工程师斩获AIGC算法offer14、50万字大汇总《“三年面试五年模拟”之算法工程师的求职面试“独孤九剑”秘籍》文章正式发布码字不易欢迎大家多多点赞算法工程师三年面试五年模拟文章地址https://zhuanlan.zhihu.com/p/545374303《三年面试五年模拟》github项目地址希望大家能多多starhttps://github.com/WeThinkIn/Interview-for-Algorithm-Engineer15、Stable Diffusion WebUI、ComfyUI、Fooocus三大主流AI绘画框架核心知识从0到1搭建AI绘画框架从0到1使用AI绘画框架的保姆级教程深入浅出介绍AI绘画框架的各模块功能深入浅出介绍AI绘画框架的高阶用法等全维度解析文章正式发布码字不易欢迎大家多多点赞AI绘画框架文章地址深入浅出完整解析主流AI绘画框架ComfyUI、Stable Diffusion WebUI、Fooocus核心基础知识16、GAN网络核心基础知识网络架构GAN经典变体模型经典应用场景GAN在AIGC时代的商业应用等全维度解析文章正式发布码字不易欢迎大家多多点赞GAN网络文章地址https://zhuanlan.zhihu.com/p/66315730617. AI算法工程师的《三年面试五年模拟》求职秘籍AIGC时代的算法工程师的求职面试秘籍持续更新中18. AIGC产业的深度思考与分析2023年3月21日微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示自从1980年首次看到图形用户界面graphical user interface以来以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。Rocky也认为AIGC及其生态会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期未来随着AIGC的全面落地和深度商用会深刻改变我们的工作、生活、学习以及交流方式各行各业都将被重新定义过程会非常有趣。那么在此基础上我们该如何更好的审视AIGC的未来我们该如何更好地拥抱AIGC引领的革新Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点希望能帮助各位读者对AIGC有一个全面的了解深入浅出全面解析AIGC时代核心价值与发展趋势2025年版
Anthropic《Building effective agents》深度解读：Agent真正的门槛，不是框架复杂度，而是可验证的任务闭环
写在前面欢迎大家关注Rocky的知乎Rocky DingAIGC算法工程师/开发工程师面试面经秘籍分享WeThinkIn/Interview-for-Algorithm-Engineer欢迎大家StarAIGC时代的《三年面试五年模拟》AI算法工程师/开发工程师求职面试秘籍独家资源【三年面试五年模拟】AI算法工程师面试秘籍Rocky最新撰写AI AgentAI智能体的深入浅出全维度解析文章深入浅出完整解析AI AgentAI智能体的核心基础知识AIGC算法岗/开发岗面试面经交流社群涵盖AI Agent、AIGC图像创作、AI视频、LLM大模型、AI多模态、数字人、传统深度学习、具身智能等AIGC面试干货资源欢迎大家加入https://t.zsxq.com/33pJ0大家好我是Rocky。核心导读这篇 Anthropic 工程博客真正值得讨论的并不是它又列了一组 Agent 工作流模式而是它把 2024 年以来 AI Agent 产业落地里最容易被忽略的一件事讲清楚了有效的 Agent 系统首先不是“让模型更自由”而是把模型的自由放进一个可观测、可验证、可回滚的任务闭环里。Rocky认为这篇文章的价值在于它非常克制。它没有把 Agent 神化成“自主智能体即将替代一切”也没有把框架包装成护城河而是把 Agent 拆回到几个朴素的工程问题什么时候只需要一次 LLM 调用什么时候需要固定工作流什么时候才值得让模型动态规划工具使用工具接口应该如何设计才能让模型少犯错这背后其实是 AI Agent 走向生产环境时的一个关键转向上半场大家关心“模型能不能做事”下半场真正重要的是“系统能不能稳定地把事做完”。模型能力是起点任务边界、反馈信号、工具设计、评测体系和人工监督才是 Agent 从 Demo 走向产品的工程地基。问题背景作者到底想解决什么Agent 这个词在过去一年被用得太宽。有些人说 Agent是指一个能长期自主运行、自己规划、自己调用工具的系统有些人说 Agent只是指几个提示词串起来、再加一点工具调用的自动化流程。Anthropic 在文章里先做了一个很重要的切分把这一整类系统统称为 agentic systems但在架构上区分 workflow 和 agent。Workflow 是 LLM 和工具沿着预定义代码路径被编排。也就是说系统知道大概要走哪些步骤模型只是步骤里的智能处理单元。Agent 则不同它让 LLM 动态决定自己的过程和工具使用方式模型不只是执行节点而是在一定边界内控制任务推进。这个区分非常关键。因为很多团队做 Agent 失败不是模型不够强而是一开始就把“工作流问题”误判成“自主 Agent 问题”。如果任务路径本来清楚硬要让模型自由规划只会增加成本、延迟和不可控性如果任务路径本来不可预测却强行写死流程系统又会在真实场景里失去弹性。Anthropic 的中心建议很直接先找最简单可行解只有当复杂度能被实际效果证明时才增加复杂度。很多应用甚至不需要 Agent优化单次 LLM 调用加上检索和上下文示例已经足够。这句话听起来保守但它反而是 Agent 工程化最重要的现实主义。AI 产品真正难的部分往往发生在第一次演示成功之后而不是 Demo 跑通当天。第一次能跑通只能说明模型有潜力第十次、第一百次、在边界条件下还能稳定完成才说明系统有产品价值。核心思路用一句主线串起来这篇文章可以用一句话概括从增强型 LLM 出发用最少的抽象和最清晰的反馈把任务逐级拆成 Prompt chaining、Routing、Parallelization、Orchestrator-workers、Evaluator-optimizer最后才进入真正开放式 Agent。这里的顺序不是简单的模式清单而是一条复杂度阶梯。越往后模型获得的自主权越大系统能处理的不确定性越强但成本、延迟、调试难度和错误累积风险也越高。Rocky认为这也是很多 Agent 团队需要补的一课Agent 不是“框架越复杂越先进”而是“任务不确定性越高才越需要更强的动态决策能力”。架构复杂度应该来自问题本身而不是来自对 Agent 概念的想象。方法展开沿着原文逻辑拆解1. 增强型 LLMAgent 系统的最小原子Anthropic 把增强型 LLM 作为所有 agentic systems 的基础单元。所谓增强不是简单把模型换成更大参数而是让 LLM 接入 retrieval、tools、memory 等外部能力。模型可以自己生成搜索查询、选择合适工具、决定保留哪些信息。这张图真正说明的是现代 LLM 应用的基本单元已经不再是“prompt - answer”这么简单而是“模型 上下文 工具 记忆”的组合。模型负责语言理解、推理和决策检索负责补充外部知识工具负责改变外部状态记忆负责跨轮次延续任务上下文。但这里也有一个容易被忽略的细节能力接入不是越多越好。工具越多模型越需要理解每个工具的适用边界记忆越复杂越容易引入过期信息或错误状态检索越开放越需要判断来源质量。增强型 LLM 的核心不是堆能力而是让模型能以低认知负担使用这些能力。这也是 Model Context Protocol 这类协议出现的意义。它试图把工具与上下文接入标准化让模型可以通过更清晰的接口访问外部世界。Rocky认为从产业角度看MCP 这类协议的长期价值不只是“接更多工具”而是把 Agent 的外部行动能力变成可复用基础设施。2. Prompt chaining把大问题拆成更容易被模型做对的小问题Prompt chaining 是最朴素也最常用的 workflow把任务拆成一串步骤每一步 LLM 处理上一步的输出中间可以加程序化检查确保过程没有跑偏。这个模式的本质是用延迟换准确率。一个复杂任务直接交给模型模型需要同时完成理解、规划、生成、检查等多个动作注意力会被拉得很散。把它拆成多个清晰步骤后每次调用只处理一个更窄的问题系统也能在中间节点加 gate 做质量控制。原文给的例子包括先生成营销文案再翻译成另一种语言先写文档大纲检查大纲是否符合要求再基于大纲写正文。这些例子都符合一个共同特征任务可以被干净拆分成固定子任务。Rocky在实际使用 LLM 做内容、代码和资料整理时也有类似体感。很多人觉得模型“不稳定”其实是把太多目标塞进一次调用里既要它查资料又要它判断价值还要它写成公众号风格还要它生成标题和摘要。更稳的方式往往不是换一个更玄的 Agent 框架而是把任务拆开先收集后判断再组织最后润色。Prompt chaining 的边界也很清楚如果任务路径固定它很好用如果任务下一步取决于输入本身、外部结果或动态环境它就会变得僵硬。也就是说它适合“可拆解”但不适合“不可预知”。3. Routing不要让一个提示词同时讨好所有场景Routing 的思路是先分类输入再把不同类型输入送到不同后续流程、提示词或工具链里。它解决的是 LLM 产品里一个非常现实的问题如果用一个通用提示词处理所有请求优化某一类输入时很可能伤害另一类输入。客户服务是最典型的例子。普通咨询、退款请求、技术支持、投诉升级表面上都叫“客服问题”但所需信息、风险级别、工具权限和回复风格完全不同。如果全部塞给同一个 Agent系统很容易在低风险问题上过度谨慎在高风险问题上又不够严格。Routing 的价值在于 separation of concerns也就是把不同问题分给不同专家路径处理。它可以是 LLM 分类也可以是传统分类模型或规则。关键不是分类技术本身而是类别边界必须足够稳定分类结果必须足够可靠。这里还有一个很重要的成本视角。原文提到可以把简单常见问题路由给更便宜的小模型把困难异常问题路由给更强模型。这是 Agent 产品化必须面对的经济问题如果每一个请求都调用最强模型、多轮工具链和复杂 Agent单次体验可能很好但商业闭环未必成立。Rocky认为很多 AI 应用最终拼的不是“能不能调用最强模型”而是“能不能把强模型用在真正需要它的地方”。Routing 本质上是把模型能力变成资源调度问题。4. Parallelization并行不是为了炫技而是为了速度和置信度Parallelization 让多个 LLM 调用同时处理任务再由程序聚合结果。Anthropic 把它分成两类Sectioning 和 Voting。前者把任务拆成独立子任务并行运行后者让多个模型调用从不同角度尝试同一任务提升结果置信度。Sectioning 适合那些天然可以拆开的任务。例如一个模型生成主回复另一个模型同时做安全审查或者自动评测时让不同模型调用分别评价准确性、完整性、风格一致性和风险。这样比让一个模型在同一次调用里兼顾所有目标更稳因为每个调用的注意力更聚焦。Voting 则适合高风险判断。例如代码漏洞审查可以让多个提示词从不同漏洞类型切入内容安全审核可以让多个判断维度分别给出结论再用阈值控制误杀和漏判。这类模式的本质不是“多跑几次就更智能”而是用系统结构弥补单次模型输出的不确定性。LLM 输出天然带有概率性尤其在模糊、开放、高风险任务里一次输出往往不该被直接当成最终事实。并行调用加聚合可以把模型的不稳定性转化成可管理的统计信号。但 Parallelization 也不是免费午餐。它会增加调用成本也会引入结果聚合问题。不同模型意见冲突时谁来裁决多维度评估之间如何加权这些都需要具体业务定义。没有清晰评价标准的并行只会生成更多看似丰富、实则难以决策的文本。5. Orchestrator-workers当子任务无法预先写死时让模型来拆任务Orchestrator-workers 比普通并行更进一步。它不是提前写好所有子任务而是让一个中心 LLM 根据输入动态拆解任务再把子任务分派给多个 worker LLM最后综合结果。这个模式特别适合代码修改和复杂搜索。比如一个 coding agent 接到任务后可能需要改几个文件、每个文件改哪里、是否需要新增测试这些都很难提前写死。搜索任务也类似系统不知道哪些信息源最相关也不知道中间发现会不会改变后续搜索方向。它和 Parallelization 长得很像但关键差异在于Parallelization 的子任务通常是预定义的Orchestrator-workers 的子任务是动态生成的。也就是说前者解决“可并行的固定任务”后者解决“需要动态拆解的复杂任务”。Rocky认为这是 Agent 从 workflow 走向更高阶系统能力的一个临界点。因为从这里开始模型不再只是执行步骤而开始参与任务结构设计。它需要判断问题空间、拆分工作量、分配资源、综合结果。这个能力很强但风险也变大拆错任务会导致后续所有 worker 都在错误方向上努力。所以 Orchestrator 的质量决定整个系统上限。它不只是一个“调度器”更像一个项目经理。它要知道任务目标也要知道哪些子任务可以独立推进哪些子任务存在依赖关系哪些结果需要回到主线重新评估。Agent 产品要做得好不能只盯着模型生成能力还要设计好这个调度层的反馈与约束。6. Evaluator-optimizer让模型在明确评价标准下自我迭代Evaluator-optimizer 是一个生成器和一个评估器之间的闭环一个 LLM 生成结果另一个 LLM 根据标准给出反馈生成器再修改直到达到目标或触发停止条件。这个模式真正有效有两个前提。第一任务有明确评价标准第二人类给出的反馈确实能改进模型结果而且模型也能生成类似质量的反馈。文学翻译、复杂搜索、长文润色、代码审查都可能符合这个条件。这里最值得注意的是“可评价性”。很多团队喜欢做自我反思、自我批判、多轮改写但如果没有可验证标准循环很容易变成语言上的自我安慰。模型会不断说“我改进了逻辑、增强了严谨性”但实际结果未必更好。Rocky认为Evaluator-optimizer 的核心不是“让模型多想几轮”而是把人类原本隐性的质量标准显性化。比如一篇技术文章评价标准可以包括是否有中心判断、是否区分事实和解释、是否解释机制、是否指出边界、是否有读者可执行的启发。如果这些标准不清楚所谓 optimizer 只是让文本变长。这个模式也解释了为什么 AI 写作、AI 编程和 AI 搜索正在从“单次生成”走向“生成-评估-修正”的工作流。未来真正有价值的 AI 产品不只是给用户一个答案而是能稳定穿过一个质量收敛过程。7. Agents当路径无法预设时才进入真正自主循环在 Anthropic 的定义里Agent 是 LLM 根据环境反馈循环使用工具、推进任务、必要时请求人类帮助的系统。它从用户命令或交互开始明确任务后进行规划和执行执行过程中通过工具结果、代码运行、环境状态等 ground truth 判断进展遇到阻塞点时暂停请求人类反馈最后在任务完成或达到停止条件时结束。这张图是整篇文章的核心。它提醒我们Agent 的关键不是“自主”两个字而是“环境反馈”。没有反馈模型只是在想象中推进有了反馈系统才能判断自己是否真的改变了外部世界。Coding agent 为什么相对容易落地因为代码世界天然有反馈测试能否通过类型检查是否报错文件是否修改成功程序是否运行。客服 Agent 为什么也适合因为工单是否解决、退款是否成功、用户是否确认都可以成为闭环信号。反过来如果一个任务没有清晰成功标准没有可靠环境反馈没有合理工具权限也没有人类监督 checkpoint那么把它做成 Agent 反而危险。自主性会放大错误长链路会累积偏差工具权限会把语言错误变成真实世界错误。Anthropic 明确提醒Agent 适合开放式问题步骤数量难以预测固定路径无法硬编码且你对模型的决策能力有一定信任。但它也带来更高成本和错误累积风险因此需要沙盒测试和护栏。Rocky认为这里有一个很重要的产品判断Agent 不是“越自主越高级”而是“在可信环境里把可验证任务规模化”。真正成熟的 Agent 产品应该让模型在需要自由的地方自由在需要控制的地方被约束。8. 两个最有落地价值的场景客服与编程Anthropic 在附录里强调了两个实践场景Customer support 和 Coding agents。它们看似差异很大一个面向业务服务一个面向软件开发但底层逻辑相同都有对话入口、外部工具、明确目标、反馈循环和人工监督。客服场景里Agent 可以通过工具访问客户数据、订单历史、知识库并执行退款、更新工单等动作。更重要的是客服问题的成功标准相对明确用户定义的问题是否被解决。一些公司甚至采用按成功解决计费的商业模式这说明 Agent 的价值可以和业务结果绑定。编程场景里Agent 的优势更明显。代码问题结构化结果可以通过自动化测试验证模型可以根据测试结果迭代修复。SWE-bench 这类任务之所以成为 Agent 能力评估的重要基准也是因为它把“会写代码”进一步推进到“能根据真实 issue 修改多文件项目并用测试反馈收敛”。但 Anthropic 也没有把 coding agent 说成完全自动化。自动化测试可以验证功能但人类 review 仍然重要因为系统要求、架构一致性、长期可维护性不一定能被单个测试集完全覆盖。这也是 Rocky对 Agent 落地最核心的判断Agent 最先改变的不是所有工作而是那些结果可验证、过程可反馈、工具可封装、人类可审查的工作。这类任务会率先被规模化而那些目标模糊、评价主观、外部状态复杂且风险高的任务会更长时间停留在人机协同阶段。实验与证据结果能支撑到什么程度这篇文章不是一篇学术论文没有给出系统 benchmark、消融实验或统一指标。它的证据主要来自 Anthropic 与多个行业客户合作构建 LLM agents 的工程经验以及 Anthropic 自身在 coding agent、computer use 等系统中的实践。因此我们不能把它当成“某个模式一定优于另一个模式”的严格实验证明。它更像是一份从生产经验中提炼出来的工程设计指南。它能支撑的结论是在当前 LLM 能力和产品约束下简单、可组合、可观测的系统更容易成功复杂框架和高自主 Agent 只有在任务不确定性真正需要时才值得引入。从证据强度看它最可靠的部分是模式归纳和工程经验这些模式确实覆盖了当前很多 Agent 产品的常见结构。它较弱的部分是缺少量化比较比如不同模式在成本、延迟、准确率、故障率上的具体差异文章没有展开。但这并不削弱它的实践价值。恰恰相反Agent 行业现在最缺的不是更多概念而是更清晰的工程判断。很多团队的问题不是不知道有 prompt chaining、routing、parallelization而是不知道什么时候该用什么时候不该用以及如何证明复杂度真的带来了收益。这篇工作的边界与可复现性这篇文章有几个边界需要特别说明。第一它主要讨论通用 Agent 工程模式而不是某个具体框架的完整实现。读者可以从中获得架构判断但不能直接得到一套可运行系统。第二它没有把安全、权限、审计、合规展开到企业级深度。对于客服、金融、医疗、法律、企业内部操作等场景Agent 的工具权限和审计日志会成为核心问题。一个 Agent 能调用工具不等于它应该拥有所有工具权限。第三它没有提供严格的成本模型。实际生产中复杂 agentic systems 往往会显著增加 token 成本、工具调用成本、延迟成本和调试成本。什么时候值得多花这些成本需要结合业务转化、人工节省、错误代价来算。第四它默认读者已经具备一定 LLM 工程能力。比如如何写提示词、如何设计评测集、如何记录中间状态、如何处理工具异常这些都需要团队自己补齐。因此这篇文章最适合被当作 Agent 架构的“决策地图”而不是“施工图纸”。它告诉你复杂度阶梯长什么样但每一级怎么在自己的业务里落地还要回到任务、数据、工具、评测和业务闭环。如果继续研究/落地应该关注什么如果把这篇文章往后推进Rocky认为有五个方向最值得关注。第一Agent 复杂度评估。团队需要建立一套判断标准单次 LLM 调用、固定 workflow、动态 orchestrator、开放 Agent到底应该选择哪一级这个标准应该同时考虑任务不确定性、错误代价、反馈可得性、工具风险、成本预算和用户容忍度。第二Agent eval。传统模型评测只看答案对不对但 Agent 评测要看过程是否可控、工具调用是否合理、错误恢复是否有效、最终任务是否真实完成。未来 Agent 产品的护城河很大一部分会来自任务级评测集和运行日志分析。第三Tool / ACI 设计。Anthropic 在附录里提到工具定义应该像 prompt 一样被认真工程化。好的工具接口要让模型容易用对参数命名清晰格式接近模型训练中常见的文本形态避免让模型做大量格式开销。Rocky认为未来会出现一种新的工程能力不是 HCI而是 ACI也就是 Agent-computer interface 设计能力。第四权限和沙盒。Agent 一旦能操作外部系统就必须有权限分层、沙盒验证、回滚机制和人工确认。特别是涉及资金、账户、生产环境、用户数据的场景没有这些机制的 Agent 只能是演示不该进生产。第五商业闭环。Agent 最有价值的地方不是“看起来像人”而是能否把可衡量任务结果规模化。客服按成功解决计费、编程按 issue 修复和测试通过衡量都是更健康的方向。真正能穿越周期的 Agent 产品不会只卖“智能感”而会卖可验证的结果。术语与概念速查概念本质适用场景主要风险增强型 LLMLLM 接入检索、工具、记忆等外部能力大多数 LLM 应用的基础单元工具过多、接口不清、上下文污染Workflow沿预定义代码路径编排 LLM 与工具路径清晰、步骤稳定的任务对动态问题不够灵活AgentLLM 动态规划过程和工具使用路径不可预测、需要多步自主探索的任务成本高、错误累积、权限风险Prompt chaining顺序拆解任务每步处理上一步输出可固定拆分的复杂生成任务延迟增加流程僵硬Routing先分类再进入专门路径多类型输入、不同风险等级、模型成本调度分类错误会把任务送错路径Parallelization多个 LLM 调用并行处理并聚合可并行子任务、多视角审核、高风险判断成本上升、结果冲突难聚合Orchestrator-workers中心 LLM 动态拆解任务并分派 worker代码修改、复杂搜索、多源分析Orchestrator 拆解错误会放大全局偏差Evaluator-optimizer生成器与评估器形成迭代闭环有明确评价标准的写作、搜索、翻译、代码任务没有评价标准时容易空转ACIAgent-computer interface面向模型的工具接口设计所有工具型 Agent工具描述不清会导致模型误用拓展思考值得继续扩展研究与思考的创新点1. Agent 的护城河会从框架迁移到任务闭环早期 Agent 项目喜欢比谁的框架复杂、节点多、链路长。但从 Anthropic 的经验看真正有效的系统反而常常使用简单模式。Rocky认为这意味着 Agent 创业和产品竞争的护城河不会长期停留在框架层。框架会开源模式会被复制模型能力会被 API 化。真正难复制的是任务闭环你是否理解用户真实工作流是否知道哪些步骤可以自动化哪些必须人类确认哪些反馈能衡量任务完成哪些工具权限可以安全开放。工具不是护城河判断才是护城河。Agent 时代尤其如此。2. Agent 工程师会从 prompt writer 变成系统设计者如果只是写几个提示词Agent 很难稳定进生产。一个合格的 Agent 工程师需要懂任务拆解、工具接口、评测体系、日志分析、权限控制、产品交互和业务指标。这会改变 AI 岗位结构。过去很多人把 LLM 应用开发理解成 prompt engineering但真正进入生产环境后prompt 只是其中一环。更重要的是全链路交付能力从问题定义到数据接入从工具封装到异常处理从模型选择到成本控制从评测集到上线监控。AI不会尊重一个人熬了多少年只会放大一个人真正能创造多少价值。Agent 工程正在把这个趋势进一步放大。3. “自主性”不是目标“可控地完成任务”才是目标很多关于 Agent 的讨论把自主性当作终点。但 Anthropic 这篇文章提醒我们自主性只是手段。Agent 不是为了看起来像一个独立员工而是为了在某些任务中减少人工步骤、扩大执行规模、提升结果质量。如果固定 workflow 能完成任务就不需要 Agent如果一次 LLM 调用能完成任务就不需要 workflow如果检索加示例能解决问题就不需要多轮工具调用。真正成熟的 AI 产品往往不是把技术上限全部展示给用户而是把刚好够用的复杂度隐藏在稳定体验后面。4. ACI 会成为 Agent 产品的关键基础设施Anthropic 在附录里讲了一个很细但很重要的例子在 SWE-bench Agent 中他们发现模型在使用相对路径工具时容易出错于是把工具改成强制使用绝对路径模型使用就稳定了。这个例子很小却非常本质。人类工程师可以理解相对路径、当前目录、上下文切换模型在长链路执行中却可能因为一个路径状态判断错误导致任务失败。解决方案不是责怪模型“不够聪明”而是设计更不容易出错的工具接口。这就是 ACI 的价值。未来很多 Agent 系统的差距不在模型 API 本身而在工具是否为模型友好地设计。一个好的工具定义本质上是在替模型减少无意义认知负担让它把能力用在真正的任务推理上。总结Agent 不是更复杂的聊天机器人而是可验证任务系统读完 Anthropic 这篇文章Rocky最大的感受是Agent 行业正在从概念热闹走向工程克制。有效 Agent 的核心不是堆框架、堆工具、堆自主循环而是从任务本身出发选择刚好够用的复杂度。能用单次调用解决就不要硬上 workflow能用固定 workflow 解决就不要硬上 Agent必须让模型动态规划时就一定要给它清晰工具、环境反馈、停止条件、评测标准和人工监督。Agent 的本质不是“模型像人一样行动”而是“模型在可验证环境里完成任务”。这句话可能没有“AI 员工全面来临”那么刺激但它更接近产业真实。因为所有能穿越周期的技术最后都要从惊艳回到可靠从概念回到结果从自由回到约束。对开发者来说真正该学习的不是某个 Agent 框架的语法而是任务拆解和系统评测能力。对产品经理来说真正该判断的不是能不能做 Agent而是这个任务是否值得 Agent 化。对创业者和投资人来说真正该看的不是 Demo 多像人而是它有没有明确反馈闭环、可持续成本结构和真实客户结果。工具红利会退潮认知红利会上升。Agent 时代真正有价值的依然是那些能把模型能力、工程系统、产品场景和商业闭环连在一起的人。参考来源Anthropic Engineering, “Building effective agents”, published Dec 19, 2024.推荐阅读1. 深入浅出完整解析AI AgentAI智能体的核心基础知识2025年可以说是AI Agent全面落地应用的元年因此Rocky在持续撰写对AI Agent的全维度解析文章深入浅出完整解析AI AgentAI智能体的核心基础知识2. 深入浅出完整解析扩散模型DDPM、DDIM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识和Rocky一起学习探究扩散模型的本质原理与和核心基础知识同时不断跟进扩散模型的最新发展。Rocky在本文中对扩散模型的本质做了全面系统的梳理与讲解深入浅出完整解析扩散模型DDPM、DDIM、SDE、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识3. 深入浅出完整解析FLUX.2、Seedream即梦、Z-image、GLM-Image核心基础知识https://zhuanlan.zhihu.com/p/19751746910491895624. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识5. 深入浅出完整解析DeepSeek系列核心基础知识深入浅出完整解析DeepSeek系列核心基础知识6、Sora等AI视频大模型的核心原理核心基础知识网络结构经典应用场景从0到1搭建使用AI视频大模型从0到1训练自己的AI视频大模型AI视频大模型性能测评AI视频领域未来发展等全维度解析文章正式发布码字不易欢迎大家多多点赞Sora等AI视频大模型文章地址深入浅出完整解析Sora、Wan2.1、AnimateDiff、CogVideoX等AI视频大模型核心基础知识7、Stable Diffusion 3和FLUX.1核心原理核心基础知识网络结构从0到1搭建使用Stable Diffusion 3和FLUX.1进行AI绘画从0到1上手使用Stable Diffusion 3和FLUX.1训练自己的AI绘画模型Stable Diffusion 3和FLUX.1性能优化等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion 3和FLUX.1文章地址深入浅出完整解析Stable Diffusion 3SD 3和FLUX.1系列核心基础知识8、Stable Diffusion XL核心基础知识网络结构从0到1搭建使用Stable Diffusion XL进行AI绘画从0到1上手使用Stable Diffusion XL训练自己的AI绘画模型AI绘画领域的未来发展等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion XL文章地址深入浅出完整解析Stable Diffusion XLSDXL核心基础知识9、Stable Diffusion 1.x-2.x核心原理核心基础知识网络结构经典应用场景从0到1搭建使用Stable Diffusion进行AI绘画从0到1上手使用Stable Diffusion训练自己的AI绘画模型Stable Diffusion性能优化等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion文章地址深入浅出完整解析Stable DiffusionSD核心基础知识10、ControlNet核心基础知识核心网络结构从0到1使用ControlNet进行AI绘画从0到1训练自己的ControlNet模型从0到1上手构建ControlNet商业变现应用等全维度解析文章正式发布码字不易欢迎大家多多点赞ControlNet文章地址深入浅出完整解析ControlNet核心基础知识11、LoRA系列模型核心原理核心基础知识从0到1使用LoRA模型进行AI绘画从0到1上手训练自己的LoRA模型LoRA变体模型介绍优质LoRA推荐等全维度解析文章正式发布码字不易欢迎大家多多点赞LoRA文章地址深入浅出完整解析LoRALow-Rank Adaptation模型核心基础知识12、深入浅出完整解析AIGC时代Transformer核心基础知识在AIGC时代中Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向成为AI技术架构大一统与多模态整合的关键核心基座大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析Transformer文章地址深入浅出完整解析AIGC时代Transformer核心基础知识13、最全面的AIGC面经《手把手教你成为AIGC算法工程师斩获AIGC算法offer2024年版》文章正式发布码字不易欢迎大家多多点赞AIGC面经文章地址手把手教你成为AIGC算法工程师斩获AIGC算法offer14、50万字大汇总《“三年面试五年模拟”之算法工程师的求职面试“独孤九剑”秘籍》文章正式发布码字不易欢迎大家多多点赞算法工程师三年面试五年模拟文章地址https://zhuanlan.zhihu.com/p/545374303《三年面试五年模拟》github项目地址希望大家能多多starhttps://github.com/WeThinkIn/Interview-for-Algorithm-Engineer15、Stable Diffusion WebUI、ComfyUI、Fooocus三大主流AI绘画框架核心知识从0到1搭建AI绘画框架从0到1使用AI绘画框架的保姆级教程深入浅出介绍AI绘画框架的各模块功能深入浅出介绍AI绘画框架的高阶用法等全维度解析文章正式发布码字不易欢迎大家多多点赞AI绘画框架文章地址深入浅出完整解析主流AI绘画框架ComfyUI、Stable Diffusion WebUI、Fooocus核心基础知识16、GAN网络核心基础知识网络架构GAN经典变体模型经典应用场景GAN在AIGC时代的商业应用等全维度解析文章正式发布码字不易欢迎大家多多点赞GAN网络文章地址https://zhuanlan.zhihu.com/p/66315730617. AI算法工程师的《三年面试五年模拟》求职秘籍AIGC时代的算法工程师的求职面试秘籍持续更新中18. AIGC产业的深度思考与分析2023年3月21日微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示自从1980年首次看到图形用户界面graphical user interface以来以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。Rocky也认为AIGC及其生态会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期未来随着AIGC的全面落地和深度商用会深刻改变我们的工作、生活、学习以及交流方式各行各业都将被重新定义过程会非常有趣。那么在此基础上我们该如何更好的审视AIGC的未来我们该如何更好地拥抱AIGC引领的革新Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点希望能帮助各位读者对AIGC有一个全面的了解深入浅出全面解析AIGC时代核心价值与发展趋势2025年版
