本文基于阿里云云小二Aivis项目实践经验系统总结了Agent构建与调优的十大关键经验清晰化预期、上下文精准投喂、身份历史清晰化、结构化表达逻辑、自定义工具协议、合理使用Few-Shot、保持上下文精简、记忆管理、Multi-Agent架构设计、以及坚持人在回路。这些经验有效解决了Agent不按预期输出、不稳定及幻觉问题为开发者提供了从技术实现到业务落地的全面指导。背景今年我们团队重点投入在“云小二 Aivis”项目中。云小二 Aivis 是阿里云服务领域的数字员工它标志着我们从传统的智能辅助客服迈向了更端到端 Multi-Agent 的数字员工能力的全新阶段。云小二 Aivis 核心是基于 LLM 的思考推理能力在 Multi-Agent 架构下结合各类MCP Tool、Browser Use、Computer Use等工具调用能力可以让数字员工更像人一样去思考和解决问题。这其实是一个非常有挑战的课题****这背后涉及到算法、工程、数据等多个维度对于云小二 Aivis 的介绍大家可以看下我们团队 TL洪林在云栖大会上的介绍分享《云小二Aivis迈向自主Agent的阿里云智能服务新形态》[1]后续也会陆续会有一系列文章发出来大家也可以期待一波~“如何构建和调优一个效果好的 Agent”始终是一个庞大且复杂的课题近一年的时间我也在集团内外多个场合进行了一些 Agent 技术分享和布道大家问的最多的问题基本上是“为什么我调了提示词Agent 效果还是这么差”“为什么 Agent 运行不稳定交互几轮后就开始不遵循指令了”“为什么 Agent 总是产生幻觉不按预期输出”我们在云小二 Aivis 项目实践中也构建了大量的 Multi-Agent 协同和上下文工程上的优化也走过不少弯路从这一些真实踩坑实践经验中我们总结出了几个我们认为行之有效的关键点希望能为正在构建 Agent、Multi-Agent 的朋友们带来一些参考价值。为什么Agent不按预期输出为什么我的 Agent 不按照预期输出这个问题我们需要拆解成两个子问题你的预期是什么也就是你期望 Agent 的输出是什么为了这个预期你的 Agent 是如何设计的围绕这两个问题可以从两个方面的角度来分析 Agent 不按照预期输出的原因一个是“预期层面”的角度另一个是“技术层面”的角度。我们先从预期层面的角度来看很多时候大家在构建 Agent 的时候总是会发出“我希望它更智能一点”或者“它应该正确回答问题”这都是常见的模糊预期。这样的预期基本上是无法指导我们对 Agent 进行有效的优化。我们需要将模糊的预期转化为具体、可衡量的清晰预期。只有将预期足够的清晰你才会拥有了一套尽量清晰的“衡量标准”。当 Agent 的输出不符合预期时你可以精确地指出哪里错了或者是提示词指令还是写的不够清晰、明白让模型产生的困惑而不是笼统地说“不符合预期”。从技术层面的角度来看提升 Agent 效果的核心方法无非两种一是优化提示词工程Prompt Engineering或上下文工程Context Engineering二是优化模型如 SFT、DPO、RLHF等。其实随着近期通义千问基座大模型版本的持续更新Agent的执行效果也越来越好模型训练的成本也变得非常高且必要性没那么大了而且尤其不适合普通玩家了。因此本文的重点将放在第一个角度如何通过上下文工程或者Multi-Agent架构层面来优化Agent效果。现在“提示词工程”早已经不是一个新概念了但是很多人其实还是没怎么理解这里面的精髓需要注意的是直接写个“提示词”并不是真正意义上的“提示词工程”。“提示词工程”的重点在于“工程”两个字也就是说在实际生产和应用的过程中并不是像我们做测试或实验Demo一样针对一个任务要求写一段提示词模型去完成一个单次调用的任务即可。而大部分情况下提示词都是在实际线上系统运行过程中动态获取和拼接的以适应更加复杂的场景。所以现在大家也意识到了这个问题叫“提示词工程”很容易将重点聚焦在“提示词”本身的书写上行业内越来越多人开始称呼“上下文工程”Context Engineering其实这两者本质的差别并不是很大因为大模型本身就是一种上下文学习In Context Learning提示词本身就是上下文中的一部分但是现在为什么重点提到“上下文工程”也是因为行业中越来越多人会关注到仅仅提示词的优化更多还是停留在提示词的质量、指令清晰度、书写规范上面很少关注到上下文的动态组合包括对系统指令的组装、对话History的组装、长期Memory的存储和读取等等更工程的层面。前段时间Manus也发表了一篇Blog《AI代理的上下文工程构建Manus的经验教训》[2]专门探讨他们在上下文工程实践的经验教训更是将这个概念进一步推广了出来。实践总结的十大Agent优化经验在云小二Aivis业务真实实践的过程中前期我们也踩过许多坑根据问题发生的原因和解决经验我总结了几个相对比较核心的建议希望能给大家带来一些参考价值。经验一清晰化你的预期核心原则避免模糊预期给到足够清晰的预期让大模型理解起来没有任何的歧义和困惑。我们先从预期层面的角度来看很多时候大家在构建Agent的时候经常会说“希望它更智能一点”或者“它应该正确回答问题”这都是常见的模糊预期。这样的预期会让大模型产生困惑**Confuse并且基本上也是无法指导我们对Agent进行有效的优化因此我们必须要将模糊的预期转化为具体、可衡量的清晰预期**。如何定义一个好的清晰预期我们可以来问自己这么几个问题1. 任务要求Task任务要求是否写得明确详细判断条件的逻辑是否写明确了你期望的判断规则是怎样模糊预期“根据查询的结果判断ECS的某端口的安全组是否放行”。清晰预期“请判断ECS输出结果中的端口安全组的放行情况如果该端口或者端口范围是-1/-1并且ip段配置的是0.0.0.0并且策略是Accept的则是完全放行如果端口上配置了特定源ip的并且策略是Accept的则是不完全放行如果端口策略是Drop的则是禁止放行”。2. 输出格式Format我期望的输出是JSON、Markdown、一段自然语言还是一个特定的函数调用JSON的Schema是什么样的模糊预期“给我一个ECS实例健康问题诊断报告。”清晰预期“输出一个包含instance_id实例ID、problem_category如’系统负载’、防火墙’等和conclusion结论的JSON对象。”3. 风格语气Style输出的语言风格应该是专业的、友好的、简洁的还是详细的模糊预期“输出一段排查过程中安抚用户的回复。”清晰预期“当诊断流程超过3个步骤仍未解决问题时以专业、礼貌、带有歉意的语气回复用户‘非常抱歉给您带来了不便正在为您进行更深入的排查请稍等片刻。”踩坑案例问答场景下的专业术语歧义在我们业务中有一个典型的“ECS实例锁定”场景。这个问题其实是有两种情况1. 业务锁定由于欠费等业务原因ECS实例本身在业务层面被锁定。2. 系统锁定由于多次输错登录密码导致的Windows操作系统层面账户被锁定。虽然我们在系统指令里对这两种情况做了区分但当客户模糊地问“我的服务器锁定了怎么办”时模型大概率会搞混并且非常倾向于回复业务锁定的解决方案而实际上客户经常高频遇到的往往是系统锁定。但是实际分析的时候你会发现大模型理解成业务锁定也是非常正常的 因为客户没有明确说是系统锁定只是说ECS锁定了因为我们的提示词里要求模型按照阿里云的视角来进行回复模型大概率就会理解成“实例本身锁定”。解决方案我们需要将这两种锁定的区别清晰的描述清楚让大模型完全清楚的理解什么叫做“业务上的锁定”、什么叫做“系统账户锁定”只有明确描述清楚两种锁定的区别才能让模型清晰地get到这两者的差异甚至可以提供一些候选工具让模型可以通过查询实例状态来执行结果进行判断1. 条件判断如果能获取到客户的实例ID调用 API 查询其业务状态如果实例确实处于业务锁定状态才提供业务锁定的解决方案如果业务状态正常就判断为可能是操作系统锁定并提供相应的排查方法。2. 明确区分如果拿不到实例ID码或者没有可用工具无法诊断的情况下也可以进一步去向客户澄清“请问您是控制台上看到实例被锁定还是远程登录到系统里面提示账户被锁定”根据用户的进一步回应来判断尽可能更清晰的给到客户精准的解决方案。通过这个精确化预期的过程你就拥有了一套尽量清晰的“执行标准”。当Agent的输出不符合预期时你可以精确地指出哪里错了或者是提示词指令还是写的不够清晰、明白让模型产生的困惑而不是笼统地说“不符合预期”。经验二上下文精准投喂核心原则“给其所需去其所扰”。模型需要且关心的信息一定要给到模型不需要且不相关的干扰信息一定要想办法剔除。这个原则听起来似乎理所当然甚至有点废话文学但在实践中我们发现很多时候Agent效果不佳的核心原因往往就是我们该给的信息没给全或不该给的信息给得太多从而引起了模型的困惑。当模型困惑时它就很有可能不会去执行任务因为没理解你的预期意图或者你的预期意图里面存在矛盾或者歧义点所以很容易反过来向你澄清问题“请问您提到的xxx是什么意思”或者按照它自己的理解去执行就极容易导致结果与预期出现偏差。踩坑案例欠费诊断的信息干扰在我们的业务中有一个场景是“判断账户是否存在欠费”。逻辑上其实比较简单就是去调用工具查询这个用户ID下的资金是否存在负数的情况即可。但是当我们真的让大模型去调用财务的相关工具API的返回结果我们会发现有非常多的字段包括可用金、冻结金额、信用金额、余额、退款金额、未结算的金额等等别说大模型这个情况人看了也得蒙如果不是对业务深入了解其实是很难知道应该如何判断是否欠费的。因此大模型的表现就出现了不稳定的情况有时候根据余额为负数判定是否欠费有时候又根据可用金为负数就判定是欠费有时候又考虑了冻结金额、退款情况等等导致多次调用大模型输出的判断结论反而是不统一的这就是严重不符合预期的情况。经过和业务的深入沟通之后因为阿里云的产品有预付费、后付费等情况所以有些金额是会预先扣除有些不预先扣除但会提前冻结等等所以最终其实只需要判断可用金是否负数即可。解决方案我们不能粗暴的把财务工具接口返回的信息“一把梭”地给到大模型就万事大吉因为这里面有太多业务领域特性的逻辑或者信息这将会导致模型按照自己想法随意发挥去做判断从而带来了不确定性正确的做法是将该给到大模型的信息经过筛选和过滤之后模型在判断欠费的时候需要关心的字段我们一定要给到模型不需要且不相关的干扰信息一定要想办法剔除。经验三身份和历史执行清晰化核心原则模型需要明确知道有几方的身份需要知道自己做过哪些事情当前执行到哪个阶段。大模型在对话中默认只有两个角色user用户和assistant大模型助手。但在我们的智能客服场景中角色要复杂得多客户、客服小二以及大模型。其中“小二”翻译成英文也是 Assistant这就极易与模型的 Assistant 角色混淆。因此必须要将身份信息非常明确的定义出来让大模型很清楚“谁在说什么谁在做什么”。踩坑案例三方角色不清晰导致模型“错乱”我们最早的版本中曾将客服小二与客户的对话直接作为 History 喂给大模型当时的想法也比较朴实就是希望模型能根据已有的对话信息来去“续写”客服小二的下一步动作。这个逻辑在初期设计的时候感觉非常合理所以也没有人发现有任何的问题。但是我们实际运行的时候就出现了一些比较奇怪的输出并不符合预期。比如某个客户说他的一台实例远程无法连接大模型开始会正常调用工具去进行诊断然后反馈结论是安全组的问题接着客户又说他的另一台实例也无法远程连接这时候由于我们直接将小二与客户的对话直接作为History喂给大模型希望让大模型基于这个对话History继续往下续写结果是模型收到这个History的影响并没有直接调用工具而是自己幻觉编造了一个结果没有做任何查询就直接说也是安全组未放行的问题这就导致了严重的事实性错误。造成这个问题的核心原因是我们将大模型实际运行的过程在组装History的时候丢弃隐藏掉了以为这些信息没有意义了让大模型只关心小二和客户的真实对话记录即可没想到模型强大的Few-Shot学习能力让模型直接将History作为了一种学习源这是因为大模型是一种Few-Shot Learner学习器很喜欢找例子比较常见的Few-Shot示例是我们在System Prompt里面去构造让模型参考但同时History中的历史对话同时也是一种Few-Shot例子大模型会学习自己之前处理过的内容来辅助生成新的内容。所以这种方式造成的结果就是它会误以为自己之前也没有调用工具而是直接进行了回复那么现在他将也效仿之前的做法不调用工具直接回复即使System Prompt里面要求调用工具模型也不一定会遵循。同时客服小二的对话风格很多时候与模型执行的History风格的差异巨大这种Mask掉历史执行记录的做法丢失了模型自己调用工具等 Action的历史记录就让模型变得十分“困惑”导致模型对角色认知产生了混乱从而产生幻觉。解决方案我们对上下文结构进行了重构1. 主线回归用户与大模型对话的完整执行过程必须还是以用户和大模型之间的交互为主线。2. 小二的对话作参考将客服与客户的真实对话作为一种参考信息Reference被明确地标识为“对话记忆”Dialogue Memory的形式注入上下文。3. 保留完整动作大模型自己真实执行过的 Action History 依然完整保留。这样一来模型就能清晰地知道当前客服与客户的对话进展到了哪一步它自己之前都做过哪些探索和尝试之前是如何理解、思考、回复的客户问题也明确知道小二是如何参考大模型的回复最终回复给客户有哪些采纳、哪些未采纳都是很清晰的。Manus的经验里也提到过一个原则“Mask Don’t Remove”比如在工具调用的时候如果当先前的动作和观察仍然引用当前上下文中不再定义的工具时模型会感到困惑以及“Keep the Wrong Stuff In”也就是“擦除失败会移除证据”。没有证据模型就无法适应。这与我们遇到情况有异曲同工之妙。经过这个调整云小二Aivis在多个场景的准确率有较明显的提升。这也再次说明不要轻易删除或篡改模型完整的探索历史即使是那些未被采纳的“错误”尝试。经验四善用结构化形式表达逻辑核心原则相对复杂的流程、逻辑可以优先考虑形式化、结构化方式表达不要只用自然语言。相比于纯自然语言尤其是最新版本的大模型对结构化数据的理解能力要比自然语言强得多。最重要的一个原因就是结构化的语言相比自然语言他尽可能的消除了歧义因为程序化的语言本身的设计就是为了“运行”天然就有着消除歧义的特性。比如你可以使用 JSON、YAML、伪代码最简单的Markdown也比纯自然语言要更结构化通过这样的结构化语言向模型传递复杂的业务逻辑或流程会更加合适。例如“先调 A再调 B再调 C”这个流程有时候用自然语言描述让调用过程参数比较复杂的时候模型未必能很好的遵循有时候就会跳过B直接调用C了但如果将其表达为类似下面的形式模型的遵循能力会好很多当然这个例子举的还是比较简单一些复杂的逻辑通过自然语言描述就比较复杂了但是通过结构化的形式就会清晰很多。经验五尝试自定义工具协议核心原则如果你的领域任务相对独特且对稳定性要求较高自定义工具协议和指令是值得尝试的。由于我们的Agent项目起步较早在2023年Qwen模型刚推出的时候我们就开始探索早期的Agent调用了在当时业界的工具调用标准尚未统一我们就自定义了一套工具调用协议。这套协议除了包含工具的Schema还在Prompt中加入了一些针对我们领域的特定要求和提示词指令。后来业界标准逐渐向OpenAI的Function Call协议以及Anthropic 的MCP协议统一我们也开始做相关的兼容测试。有趣的是我们发现在许多场景下我们自定义的协议在执行逻辑的准确性和稳定性上反而优于通用的标准协议。我的理解这可能是模型在为通用协议进行训练时其思考和调用逻辑相对收到了训练数据的影响和固化。当你的领域化需求遇上它的内在逻辑时它会默认按照训练语料中的方式去理解和调用所以不会完全遵循你的指令。因此我们现在大部分的场景Agent从调用的协议从23年到现在还是以自定义的这套协议为主经受住了诸多领域场景的考验和时间的检验。经验六Few-Shot要合理使用核心原则灵活性强的场景慎用Few-Shot特定任务中建议用多样化的Few-Shot。很多时候为了提升模型在任务上的稳定性和表现有时候指令写的再详细、再清晰模型也还是会有幻觉或者不完全理解的时候这个时候写上几条Few-Shot作为例子模型的稳定性和指令遵循效果会迅速提升。对于人来说这个Few-Shot就有点像教科书里的例题假如只让你读一段教科书里的概念、术语和公式让你看完后直接做题其实还是挺大概率会做错的但是有例题的情况下就一目了然能够比较快的提升学习效果而且例题越多学生就更容易理解。但也不是所有情况都适合用Few-Shot在有些时候随手写的几条Few-Shot反而限制了模型的发挥空间甚至有些时候会起反向作用引入幻觉。所谓“成也Few-Shot败也Few-Shot”。关于这方面我的建议是单任务中善用 Few-Shot单任务指的是这个大模型的任务主要是完成一个特定的任务要求比如从一堆对话数据中抽取某些参数或者是判断安全组是否放行。这样的任务为了提高稳定性我们会使用 Few-Shot。但是这里还有一个建议就是很多大模型会在宣传的时候说可以不用写Few-Shot或者写1-2条Few-Shot即可这个我测试的情况来看多给几条不同类型的Few-Shot增加多样性的效果是最好的。比如说如果你的任务是抽取参数那么你可以ECS的实例ID、RDS的实例ID、域名、备案号这些都提供一下不同产品线都选择一个例子甚至没有参数的情况也可以提供一个例子能让大模型更加清晰的知道什么情况下是不提取的。灵活任务中慎用 Few-Shot在一些比较灵活的任务上我们尽量减少使用 Few-Shot。因为在这个情况下我们比较期望模型能够灵活、智能的处理各种情况如果给了Few-Shot就很容易让模型“过拟合”到这些示例上丧失通用性和灵活性。尤其是遇到FewShot里没见过的情况它可能会生搬硬套示例导致更严重的错误。就比如说我们期望大模型能够根据工具返回的结果自主决策给客户的回复这个情况下如果我们写了Few-Shot有时候模型就会直接模仿Few-Shot中的句子和话术模板来生成回复哪怕不是这个场景也会强行硬凹一个别扭的回复或者当上下文很长的时候甚至都会搞混Few-Shot和真实工具的返回结果从而直接给出错误的回复。因此对于灵活、开放性任务如果Agent表现不佳与其硬塞 Few-shot不如尝试增加更明确的任务要求或开启模型的“深度思考”让模型多思考一下再输出效果可能会比提供Few-Shot更好。经验七保持上下文的“苗条”核心原则在不损失性能的前提下尽可能对上下文进行“瘦身”。虽然现在的大模型都号称支持百万甚至千万级Token上下文但实际测试会发现当上下文长度超过一定长度例如1万Token以上模型对历史信息的遗忘率会显著增加就比如“大海捞针”Needle In A Haystack这类benchmark的准确率上看token数量越多超过某个阈值之后就开始急速下滑。甚至一些你写在前面的系统指令里的核心要求都很可能会被模型间歇性遗忘造成Agent行为的极度不稳定。如下图中对Claude 2.1版本的评测虽然评测时间有点早了但是结论基本还适用。仍然是不要“一把梭”地将所有信息都塞给大模型。这不仅会增加成本、降低速度更重要的是会严重影响效果。建议通过RAG等技术动态地筛选和提供当前任务真正需要的信息。这与我们的第二个原则“上下文精准投喂”不谋而合不过本条建议更多强调的是即使上下文精准提供的情况下也请尽量给上下文“瘦身”不要提供太多不必要的token信息比如一些重复的提示词要求一些对最终结果影响不大的提示词要求等等都可以进行删减和精简可以测试下某些指令移除之后模型的反应是否敏感如果不敏感就可以进行精简。一个高效的 Agent一定是精雕细琢的结果。经验八使用记忆管理来避免模型遗忘核心原则重点信息多次增强提示上下文压缩减少历史对话轮次外部存储帮助实时唤起更久的记忆。记忆Memory管理是近一段时间的一个比较火热的话题一方面除了上面讲到的随着Agent多轮对话的轮次也越来越长上下文窗口越来越大模型的**“遗忘”就越来越明显甚至有时候连系统指令都开始间歇性的遗忘。再一个情况就是有些Agent场景需要模型记得上几次甚至前段时间对话中的关键信息或者需要模型有能力持续记忆用户的个性化特征针对用户的个性化的特征进行生成。因此对多轮对话的记忆做有效的管理才能让Agent越来越有“记性”**。在大模型目前实现的底层原理中在不进行训练的前提下模型是不会因为对话上下文的增加而动态更新模型权重的所以这个记忆只能是在大模型的外部做文章也就是通过一个外部的模块来决定是否将这些需要记忆的信息作为上下文Context给到大模型。一般来讲这个外部模块就可以称为记忆管理模块这里面其实有好几个不同的策略。**1. 重点信息多次增强提示对于一些重点的信息比如在阿里云服务场景中客户提供的实例ID信息、操作系统版本、公网IP等信息在前面客户提供过或者通过工具获取到过但是经过多轮对话之后突然提到的时候模型可能会有所遗忘还有可能还会去询问客户这些信息就会感觉很不智能。一个比较好的做法是这些重点信息在对话链路中多次增强提示比如通过一个外部模块定期将这些信息追加到对话中类似一种定期“复习”**的感觉或者在工具调用的时候这些核心信息会作为类似“内部变量”持续传入传出不同工具的入参出参中增强模型对这些信息的记忆能力避免遗忘。**2. 上下文记忆压缩**随着对话越来越长History列表也会变得非常冗长模型很多时候比较关心近期35轮的聊天信息和话题那么这些早于最近35轮之前的信息其实随着对话的持续进行越来越不重要但是如果一直在History中存在无疑会持续增长上下文窗口这就不符合我们第七条经验了。因此在组装History的时候可以将一些比较早期的对话记录通过summary的方式总结提取成一些核心信息即可这样就能大量节省上下文窗口和token量同时还不对当前对话产生较大的影响这就是对记忆进行压缩只挑重点的信息记录这个有点像我们计算机里的“内存”。**3. 外部记忆存储即使是对历史History进行不停的提取压缩时间久了还是会有很多信息尤其是时间周期比较长的一些信息比如客户上次的咨询历史、客户的一些个性化画像特征都需要进行记录在需要使用的时候就要想起来因此除了“内存”我们还需要有“外存”也就是将一些需要长期记忆的信息记录到一个专门的Memory的池子里面在判断当前对话中需要调用的时候可以专门有个记忆管理模块动态去查询然后注入到当前轮次的上下文中或者将这个记忆管理模块做成一个工具Tool让主链路Agent自行决定什么时候调用查询并且需要对这个“外存”有着“读”和“写”**的操作能够做到在该需要记录的时候记录该需要读取的时候读取。当然关于Memory管理这块的内容也是有很多细节问题实现起来其实也比较复杂比如要抽象出提取哪些信息作为关键信息这些信息以什么形式存储信息是否需要分类或者分层存放如何查询和读取这些细节都决定着记忆模块的效果好坏如果细节处理不好依然会让Agent给人一种“不太聪明”的感觉~经验九 使用Multi-Agent来平衡可控性与灵活性核心原则Workflow提升可控性LLM自主决策提升灵活性好的Multi-Agent设计既可控又能灵活。在构建 Agent 时我们既希望它能按照预期的路径可控地执行又希望它在遇到未知情况OOD时能有一定的自主探索能力。在我之前的文章里有比较大的篇幅讲过Multi-Agent架构是实现这种平衡的有效手段。有兴趣的朋友们可以来阅读《如何构建和调优高可用性的Agent浅谈阿里云服务领域Agent构建的方法论》这篇文章中的**“Agent规划层的权衡”** 段落部分。通常我们会将大部分的场景进行一些拆分比如主Agent负责用来进行调度决策而子Agent则负责用来进行一些固定、复杂流程链路Workflow的诊断、查询。主Agent (调度决策)负责整个任务的意图路由、子模块调度、最终生成的决策通常使用LLM大模型来进行自主决策通过上下文中构造业务经验来帮助模型进行约束通常负责一定的灵活性。子Agent/工具 (执行诊断)将一些逻辑复杂的诊断、分析任务封装成独立的子Agent或Tool供主 Agent 调用。这些子 Agent 内部可以采用纯Workflow编排也可以是一些小的单任务的LLM Agent以保证执行速度和准确性。这样一些非常强流程需要稳定性较强的模块都可以收敛到这里面主要是基于流程规则引擎 单任务的LLM结合的形式来进行实现。通过这样的Multi-Agent的这种架构设计既实现了可控性与灵活性的平衡也便于维护和扩展在线上应用的效果相比传统的单Agent形式都要好很多。关于这两部分结合的内容在之前的文章中有较多介绍此处就不再赘述了。经验十 只有HITL才能做出更好的Agent核心原则只有坚持人在回路HITL深入业务场景中才能做出好的Agent。这里回到Agent最本质的定义我曾在《为什么一定要做Agent智能体》文章中写到过Agent就是让大模型**“代理/模拟”「人」的行为使用某些“工具/功能”来完成某些“任务”**的能力。那么也就是说想要做好Agent你必须要先知道“人”是怎么做的需要问自己几个问题人是如何识别这个问题的什么情况应该查哪个工具查到工具之后如何回复给客户也只有这样你才能做出像人一样思考、推理、查询、解决问题的数字员工Agent。很多时候在构建Agent的时候会忽略这一点如果只从需求出发你不清楚人的具体思考过程、操作过程这样就很容易写出一些任务要求模糊的Agent导致大模型自由发挥效果很难达到人的预期。做个比喻就像**“明星模仿秀”**一样如果你要模仿某个明星 不去深入研究这个明星的造型、动作甚至演唱技巧去尽可能找到他的明显特征你就很难模仿的像这个明星。另外人在后期使用Agent的时候也需要持续给出反馈根据反馈中的错误信息来不断的给出优化方案这就回到了我们的经验一人也必须要先给出清晰预期然后才能不断指导Agent的持续迭代优化。这个经验听起来感觉是很简单的但实际上操作起来也是最难的除非使用Agent的人也是开发Agent的人因为很多时候想了解到“人”的具体操作过程本身就很难就比如我们做云小二Aivis的时候我们研发同学并不是真的了解客服是如何实际思考、处理问题过程这个过程就需要不停的与客服、督导沟通甚至去客服现场观察客服的真实接单过程只有去深入了解客服小二同学实际的处理逻辑和处理习惯才能做出更适合客服小二使用的云小二。总结以上是我们在构建“云小二Aivis”过程中在上下文工程、Multi-Agent实践等多方面的一些感受和体会。之前我也分享过一篇的文章是《如何构建和调优高可用性的Agent浅谈阿里云服务领域Agent构建的方法论》主要侧重于提示词优化、Mutli-Agent权衡和领域数据集成。本文则更聚焦于上下文工程、通信协议等更加工程层面的思考希望两篇文章的结合能为您带来更多启发。如果大家有任何问题或者在实践中遇到了其他挑战欢迎在评论区留言交流。我们也希望能借鉴大家的智慧共同提升构建Agent的能力。我们后续也会分享更多关于云小二Aivis的技术实践。本文是我个人的一些探索与心路历程仅是一家之言行文仓促如有疏漏还望各位不吝指正。如何学习AI大模型作为一名热心肠的互联网老兵我决定把宝贵的AI知识分享给大家。 至于能学习到多少就看你的学习毅力和能力了 。我已将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示。三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。
 获取与实战)
