仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
打算把agent相关内容拉出来专门写一个系列，持续更新。
作为第零篇，先看看Google的Agents白皮书和Anthropic开发者在agent开发上的一些经验。这里只整理一些关键的信息和自己的理解；更详细具体的内容可以看原文。
原文链接：https ://archive.org/details/google-ai-agents-whitepaper
白皮书内容主要分三部分：
whatisanagent，这部分是对agent的一个大致定义和理解
Tools，工具这块单独拉出来说，白皮书顺便也给G家的工具做了一下广告
实践的例子，用LangChain和Vertex做的agent，Vertex也是G家的
现阶段，粗暴地说agent就是LLM+工具构成的一个能和环境交互并完成任务的系统。
一个典型的（GenerativeAI）agent可以分成三大块：
Model：系统的思考中枢
Tools：agent的“手脚”，提供专业的处理能力，以及和环境交互的桥梁
Orchestration：编排层，主责协调和管理系统中各个组件的交互和协同
模型：现在可用的强大LLM已经很多，基本上开箱即用，不训练也是可以的。当然有些模型没有针对functioncall等工具调用能力做过优化，如果是涉及到较多functioncall，甚至有几百个上千个接口（这个数量已经足够构成一个单独的垂域了），那么针对场景进行一定的优化正常来说还是有收益的。
工具：现在最火的就是MCP了，基本上也是开箱即用。如果有些私有工具，那么也可以按照MCP的方案套一层就行了。
那么我们在开发的时候，操作空间比较大的应该就是在orchestrationlayer。
简单来说编排层决定了模型获取信息和决策的方式。Orchestration中这个loop可长可短，具体取决于任务的难度和模型、工具的能力。
对比一下model和agent，分别从知识范围、推理模式、工具能力和逻辑编排这几个维度来看：
知识范围上，显然agent相比model有更动态&更加广泛的知识范围
推理模式上，model一般是单次的，而agent能够和整个系统的其他模块进行多次交互
工具能力上，agent能够调用外部工具完成任务
逻辑编排上，agent有多种reasoning框架可以使用：CoT、ReAct等，当然model也能用，但是一般只能以prompt的形式单次线性地执行
ReAct
CoT
ToT等
当然PE发展很快，还有很多其他方法。利用这些方法，agent能够自主决定下一步应该干什么。
prompt像是给agent提供了一个战略，在这个战略下，模型自发地根据当前情况设计具体战术。
谷歌的框架里，模型能够与之交互的主要工具类型有三种：
Extensions，扩展程序
Functions，函数
Datastores，数据存储
Extensions对实际执行任务的API进行了一层封装，同时能够提供说明和样例，是模型和环境直接交互的桥梁。
而Functions和extensions相比，有两点主要的区别：
1、模型给出function的调用命令和参数，但是并不实际执行
2、extension的执行在agent-side，而function在clientside
那么什么情况下会选择用function函数而不选择extension呢？举几个例子：
API的调用需要在程序的另一层进行，而不是agent架构
安全或身份验证限制阻止agent直接调用API
API的调用涉及(人工)审核
调用中包含额外定制的业务逻辑
最后还有一个Datastores，通常是向量数据库之类的。
几个工具的总结：
现在模型的通用能力都很强了，不过用到agent上，还是有可能出现一些场景和工具，超过了模型的预训练范围，那么就需要通过一些方法提升模型的领域能力。这些方法包括但不限于：
In-contextlearning：推理的时候加上few-shotexample
Retrieval-basedin-contextlearning：根据输入query，搜索一些最相关的工具和样例
Fine-tuningbasedlearning：直接训练内化
Anthropic这篇博客介绍一些实际的agent经验，更加接地气一点。
原文链接：https ://www.anthropic.com/engineering/building-effective-agents
博客的作者还有一个相关的小演讲：https ://www.youtube.com/watch?v=D7_ipDqhtwk
讲agent之前，先讲讲workflow。
workflow我们日常已经用得很多了，写代码的逻辑，日常做饭的操作，都是workflow。这些工作一个特点就是任务相对是well-defined，大概有什么步骤，每个步骤干什么相对清晰，大不了加一个branch或者确定的loop。
总结几种常用的workflow。
1、PromptChaining
PromptChaining将任务分解为static的子step，前一步的输出作为下一步输入。
PromptChaining适用于「任务可明确拆解」的场景（如先生成营销文案，再翻译），需通过切分子任务来降低单次LLM调用的复杂度的情况。
2、Routing
Routing通过分类（LLM或传统算法）将输入导向不同的下游处理模块。
Routing适用于「输入类型差异大且需专用处理」的场景，如客服问题分类：退款请求→财务工具，技术问题→知识库检索；或者「成本优化」的场景，如简单问题分到小模型如Haiku，复杂问题用Sonnet。
3、Parallelization
Parallelization将任务同时下发给下游多路处理模块，并把多个下游模块的结果聚合起来，经过处理获得最终输出。
Parallelization适用于「需加速处理或多样化视角」的场景，如多维度评估模型性能，又或者关键任务需冗余验证（如敏感内容过滤需多数表决）。
Parallelization有两种变体：
Sectioning：独立子任务&执行（如内容生成与审核同步进行）
Voting：同一任务多次运行，聚合多次结果（如多LLM评审代码安全性）
4、Orchestrator-Workers
Orchestrator动态分解任务，把子任务分配给Worker，最后合成结果。与Parallelization不同的是，这些子任务不是预先定义好的，而是根据输入动态生成的。这里其实已经有些agent的感觉。
这种workflow适用于「复杂且不可预测的任务」的场景，如跨多文件代码修改，需动态分析依赖关系；或者「多源信息整合」，如研究任务需从不同数据库检索并交叉验证。
5、Evaluator-Optimizer
Generator产出结果，evaluator提供feedback，并循环优化（类似人类写作的迭代修订）。
Evaluator-Optimizer适用于「存在明确评估标准」的场景，比如翻译的语义保真度；或者「需多轮改进」的场景，比如复杂搜索任务，evaluator根据已有搜索结果决定是否继续搜索。
LLM+workflow已经cover了很多我们日常使用的场景，比如手机上用语音助手操作闹钟就是一个LLM+workflow的流程。RAG也是一种workflow，先搜索后回答。这些使用LLM的workflow系统其内部的调度主要依赖人的设计。
人设计的workflow相对固定，而agent则相对灵活。那是不是agent总是优于workflow，答案是no：
灵活的调度，其背后是复杂度和成本的增加，对应的风险也有提升，如果业务没有那么复杂，那么单次的大模型调用基本可以满足需求，没有必要非要上agent。
一个典型的agent流程图：
和workflow相比，agent有这些特征：
自主性：LLM自主规划步骤、调用工具，无需预先定义路径
环境交互：常常需要依赖工具执行结果作为事实依据
agent适用于「开放性」的问题，比如GitHubIssue的修复，期间需动态分析代码库。agent在执行过程中，需要做一些风险控制：
设置停止条件（如最大迭代次数），防止agent陷入死循环，这个在目前阶段是比较常见的情况
沙盒测试和监控工具调用（防错误累积）；正常来说agent会有至少两三次调用，期间有多次操作比如工具调用，这些可能需要结构化输出的场景模型还是有可能出错的，需要对格式和内容进行一定的修正；另外模型写代码是比较天马行空的，有可能写出移除路径之类的代码，这在生产环境风险很大，最好搞个沙盒环境，免得被删库
Anthropic从agent的实践中总结了一些实际经验，给了两个适用agent的案例。
1、案例一：CustomerSupport
适用原因：天然对话流与工具调用结合（调取订单数据、触发退款等操作），可量化成功指标（如按解决率计费）。
2、案例二：CodingAgents
适用原因：结构化问题空间（代码可通过测试验证），自动化反馈驱动迭代（测试失败→重新修改代码）。
不过代码agent目前也还有一些问题，比如功能性验证≠系统兼容性，仍需人工审核（如架构设计一致性）。这个目前的复杂度还是比较难由agent自己完全handle。
Anthropic给出一个重要经验：工具设计的质量直接影响agent效果，需要像设计人机交互（HCI）一样重视agent-computer接口（ACI）。在把工具给模型使用前，先让人类的使用者试下，看是否会在使用时遇到问题，比如参数的理解有没有问题，接口的设计是否合理，如果人类使用起来有困难，那么模型大概率也会遇到问题。
在SWE-bench的project中，工具优化的耗时占了大部分开发时间。
有几条具体的实践原则：
格式优化：选择LLM易处理的格式，如避免JSON转义，优先Markdown；或者其他模型能在internet上看到的格式，保持阅读和生成的格式一致性
绝对路径：SWE-bench代理中，用绝对路径替代相对路径能减少一些错误
开发文档：包含示例、边界说明、常见错误，像给人类开发者用一样
区分相似工具：比如”文件编辑”需明确是全量重写还是差分更新，并考虑哪个方法对模型更友好（比如查分更新，只修改文档的一部分，那么就需要模型具备补全的能力）
博客作者的演讲给了三个agent开发中的观点。
1、Don’tbuildagentsforeverything
agent不是workflow的升级版，不要把原有的workflow都替换成agent。workflow和agent虽然略有重叠，但是更主要的应该是互补的关系，合作的关系，不是上下级的关系。
workflow可以处理确定性高的任务，而agent擅长处理模糊的问题。
workflow成本更低，而agent可能会在一个任务消耗极其大量的token（百万甚至更多），所以要好好考虑成本问题（以及耗时）。
2、Keepitsimple
Agentsaremodelsusingtoolsinaloop
Anthropic认为重要的agent组件：
environment
prompt
tools
把精力放在优化这几个重要组件上，不要过度设计。
3、Thinklikeyouragents
agent可以说每次处理都是从零背景知识开始，模型能够看到的信息全都在prompt里了，所以请在prompt里把重要的相关信息都提供清楚，包括详细清晰的背景和任务描述，准确的工具和环境说明，还有详尽的历史记录和反馈。
如果人类无法在模型的环境下工作（能看到的prompt，能操作的工具），那么模型效果不好也就可以理解了。因此记得「设身处地」，跟模型「换位思考」。
agent的三大模块：模型，工具，和调度（prompt+相关配套）
agent开发三个理念：（1）不要拿着锤子看啥都是钉子，agent不是workflow的升级版，agent和workflow解决的问题是不一样的，不要到处套用（2）不要过度设计agent系统，先尝试从环境、工具和prompt入手优化（3）换位思考，从agent的角度出发思考，如果一个任务人难以完成，agent一样会遇到问题
Reference
进技术交流群请添加AINLP小助手微信（id:ainlp2)
请备注具体方向+所用到的相关技术点
关于AINLP
AINLP是一个有趣有AI的自然语言处理社区，专注于AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括LLM、预训练模型、自动生成、文本摘要、智能问答、聊天机器人、机器翻译、知识图谱、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLP小助手微信(id：ainlp2)，备注工作/研究方向+加群目的。
