1. 项目缘起与整体思路1.1 我为什么开始整理这套“Agent技能树”做AI Agent开发这一年多我最大的感触是真正卡住大多数人的不是模型能力而是“怎么把模型能力落成一个能稳定干活的Agent”。市面上教程很多但大多只教你怎么调API、怎么写一个ReAct循环。可实际项目中你会发现Agent经常“看起来聪明干起活来却像个实习生”——让它查资料它给你编让它调工具它参数传错让它多步推理它中途跑偏。问题出在哪出在缺少一套系统化的“技能体系”。我整理这套agent-skills的核心目标就是想解决三个具体问题如何让Agent稳定地完成多步骤任务而不是偶尔成功、经常翻车。如何让Agent高效地“使用工具”而不是拿到工具不知道怎么下手。如何让Agent具备“自我纠错”和“边界感知”能力而不是无脑执行搞出大问题。这三件事恰恰是Agent从“demo玩具”走向“生产工具”的必经之路。1.2 这套技能体系解决什么问题先说清楚这套agent-skills不是某个具体框架的教程它是一套方法论实操模式的组合。你可以把它理解为“Agent开发者的能力地图”——帮助你快速定位当前项目卡在哪该补哪块技能。我整理的内容适合以下几类人刚入门Agent开发被各种概念ReAct、Tool Calling、RAG、Memory绕晕的新手。已经能跑通简单Demo但一做复杂任务就稳定性和效果差的老手。需要在业务中落地Agent但团队里缺乏可复用的模式模板的工程负责人。它不像论文那样抽象也不像代码注释那样琐碎。它更像是一个“经验清单”——把我在实际项目里踩过的坑、验证过的方案、沉淀下来的模板按技能维度梳理出来。2. 核心技能维度拆解2.1 技能一任务拆解与规划能力Agent和普通AI对话最大区别在于对话只需“回应”Agent必须“干活”。干活就意味着任务拆解。这个技能我拆成三层第一层目标理解层。模型能否从用户的模糊需求中提取出可执行的目标。比如用户说“帮我整理一份市场调研报告”好的Agent应该在执行前拆出调研对象是谁报告给谁看篇幅要求数据来源需要哪些图表第二层步骤规划层。拆解成一个有序的步骤流程图。比如“先收集数据、再清洗数据、然后生成图表、最后撰写结论”。这一步看起来简单但实际极容易出错。模型经常跳过关键步骤或者步骤之间逻辑不连贯。第三层动态调整层。真实执行过程中Agent必须允许自己“改变计划”。比如原计划第一步是抓某个网站结果该网站改版了Agent理应能识别这个异常调整方案而不是死磕到底或者直接放弃。实际操作中规划层最实用的一个技巧是倒推法先让模型自己回答“这个任务的最终产出物是什么”然后再问“要得到这个产出前一步必须完成什么”。这样一步步倒推得到的步骤列表往往比正向思考更加严谨。我实测过同样的模型和Prompt用倒推法写出的执行计划出错率能降低30%左右。2.2 技能二工具调用与API交互Agent技能的第二个核心是工具调用。这一块我不想讲概念直接说几个我踩过的坑。坑一工具描述写不清。Agent调用工具靠的是模型的语义理解。如果你的工具描述写得含糊模型很容易选错工具。举个例子你有两个工具一个“获取当日天气”一个“获取历史天气”。如果描述不够明确Agent隔三差五就选错。解决办法是在描述里写明调用条件和典型场景比如“当用户询问今日天气时使用当用户询问过去某天天气时使用另一个”。坑二参数映射错位。模型从用户话语里抽取参数要做到准确实属不易。比如用户说“帮我订明天下午三点的会议室”你定义的参数是date_time要求ISO格式模型往往直接输出“明天 15:00”这种人类写法。解决办法是在工具定义里写清楚参数格式的示例值不要只写类型和描述。坑三忽略工具的执行状态码。很多Agent实现只关注“工具返回了什么”不关心工具本身报了什么错。这样导致的结果是工具明明返回了错误信息Agent却还在硬着头皮处理错误结果最后产出垃圾输出。我在项目中强制约束任何工具调用都要检查执行状态出错时先返回错误信号让模型介入决策。我还有一个经验工具调用的成功率很大程度取决于你是不是做了“工具调用演练”。上线前用一组典型场景去测试Agent的选工具和传参能力把失败的案例收集起来针对性地修改工具描述或少量样本示例。这一套循环做两三轮工具调用的准确率就能达到生产可用级别。2.3 技能三上下文管理与记忆机制Context是Agent最值钱的资源也是最容易浪费的资源。我见过太多失败的Agent案例根本原因不是模型不够聪明而是把上下文窗口塞满了无效信息导致模型“该记的记不住不该记的全记住了”。我总结了一套上下文分层的办法核心指令层永远在Top系统提示词、安全约束、任务目标。这部分不能被对话内容稀释。持久记忆层用户的偏好、历史关键结论、长期事实。这部分在每次对话开始时注入。短期工作区当前任务的中间产出比如已抓取的数据表格、当前执行计划。这部分可以动态增删随着任务推进不断覆盖。临时参考层模型检索到的外部资料、临时搜索结果。这部分要用摘要的方式存放尽量避免把长文档原封不动塞进去。我常用的一个做法是每次工具调用结束后先让模型用两三句话总结“这次调用获得了什么有效信息”再放到上下文里。这样做看起来多了一步模型调用但带来的收益非常明显——后续的推理质量大幅提升因为模型不用在原始返回的一堆JSON里翻找关键信息。2.4 技能四自我纠错与反思机制Agent最让人头疼的一点做错了还不自知一本正经地给出错误答案。所以我专门把这部分单列成一个技能维度。自我纠错机制的核心不是让模型“思考得更认真”而是给模型提供“验证缺口”。什么叫验证缺口就是让模型在给出答案之前先自问三个问题我的结论有事实依据吗依据来自哪里我的执行步骤中有没有哪一步是不可靠的有没有我忽略的边界情况具体到实现上我推荐一种“双层反射”模式第一层执行完任务后模型先自己Review一遍输出检查是否满足任务要求格式是否正确逻辑是否自洽。第二层如果任务涉及数字或事实强制调用一个外部工具比如计算器、搜索结果、数据库查询去验证关键结论。这套机制看起来会多消耗一些Token但对于结果可靠性要求高的场景比如代码生成、数据分析、金融报告这笔开销是值得的。2.5 技能五多模态与多格式处理现阶段的Agent开发几乎不可能绕开多模态和多种文件格式的处理。纯文本场景反而越来越少见。实际项目里用户传来的可能是PDF、Excel表格、图片截图、甚至一段录音。针对这个维度我最想强调的一点是不要试图让大模型直接处理原始文件先把文件转成统一的结构化中间格式。比如PDF文件先用解析工具转成Markdown或者纯文本再交给Agent。如果是Excel先转成CSV并且把列名、单位说明好。如果是图片先做OCR提取文字再做视觉理解。这一步“前置结构化”可以大幅度减少模型出错概率因为大模型处理规范化文本的性能远好于处理乱七八糟的原始文件。3. 实操过程与核心实现细节3.1 从零搭建一个具备基础技能的Agent这部分我用一个具体案例来演示搭建一个“会议纪要整理行动项追踪”的Agent。这个场景足够简单但又覆盖了任务拆解、工具调用、上下文管理和自我纠错多个技能点。第一步明确工具集。会议录音转文字工具ASR。文本摘要工具。日历API用于查询与会者日程判断行动项截止时间的合理性。文档存储工具用于保存最终纪要。第二步设计系统提示词。我强调“角色能力边界工作流程”三段式你是一名会议纪要助手。你的工作是把会议录音转换为结构化纪要并提取行动项。 你只处理与会议相关的信息对于不确定的内容必须标注“待确认”不可编造。 工作流程先转写再分段然后提取议题和结论最后生成行动项并保存。这段提示词里最关键的其实是“不可编造”和“待确认”。这能极大减少模型输出幻觉内容的风险。第三步写工具调用逻辑。核心代码如下这里用类Python伪代码表达def run_agent(transcript_file): # 1. 转写阶段 raw_text asr_tool.transcribe(transcript_file) # 2. 分段摘要阶段注意用分段法而不是全文摘要 segments split_by_topic(raw_text) summaries [summarizer.summarize(seg) for seg in segments] # 3. 提取行动项阶段 action_items extract_action_items(summaries) # 4. 校验动作项是否包含负责人、截止时间、具体任务 for item in action_items: if not item.get(assignee) or not item.get(deadline): flagged 待确认 # 5. 保存 doc_store.save({summary: summaries, action_items: action_items}) return action_items注意我在第4步用了一个“校验”环节这就是前面说的自我纠错机制的在真实场景里的落地实现。不要相信模型一次性提取的完整度强制加一道“字段是否齐全”的程序化校验。3.2 调试技能时的关键参数配置调试Agent技能的“手感”和调传统机器学习模型完全不同。我整理了一套核心参数清单以及我常用的初始值配置项作用建议初始值调试方向temperature输出随机性0.2事实精准场景调低创意场景调高top_p核采样0.9一般不动max_tokens单次生成上限根据任务定任务复杂时宁可拆步骤工具调用阈值触发工具调用的置信度0.6过低则频繁误调过高则漏调反思触发条件何时做二次校验涉及数字/日期/API视业务风险程度调整这里特别想提醒一个经验不要一上来就调temperature。多数Agent效果差不是随机性问题而是提示词或工具定义有问题。我见过团队调了一下午temperature最后发现是工具描述里参数单位写错了。优先排查结构性错误再调随机性参数。3.3 用评测集“打磨”技能的实操方法技能体系的建立是动态迭代的你需要一套评测集来持续验证和回归。我的做法是准备20-30个典型任务覆盖正常场景、边界场景、错误输入场景。比如会议纪要这个场景正常一段40分钟的销售例会录音。边界录音只有5分钟且只有一个人说话。错误输入上传的是一段音乐而不是人声。然后跑一遍全流程记录每一类场景的表现。正常的要稳定成功边界的要“不崩溃”错误输入的要“拒绝执行”。把失败案例加入评测集的“回归清单”每次修改后重新跑一遍确保不引入新的问题。这套流程做完一遍后你的Agent技能基本就能从“demo级”跨入“可复用级”。4. 常见问题与排查思路实录4.1 Agent“答非所问”怎么排查状态表现为Agent没有报错但输出内容和用户问题对不上。我建议排查顺序如下第一查上下文占用。很多情况下Agent把大量历史内容堆在上下文中导致注意力分散。查看发送给模型的Prompt里实际包含多少历史内容先做裁剪。我经常发现某些会话历史占了上下文的80%模型被历史信息“带跑”了。第二查工具返回结果。有些工具返回的内容格式极差比如全拼接的长JSON、没处理的Markdown符号。模型接收后部分内容变成了噪声。把工具输出做summary和结构化往往能解决一半“答非所问”。第三查指令冲突。系统提示词里的要求和用户当前的问题存在隐性互斥。比如系统提示“只回答与会议相关的内容”用户问“现在的天气”模型就很有可能陷入一种“不知道该不该回答”的纠结。这一类冲突日志中通常不显示需要人工读Prompt日志才能发现。4.2 Agent“绕圈子”不结束任务怎么办这个问题的本质是循环缺少终止条件。Agent不断地重新规划、重新尝试就是不输出最终答案。我的解决办法有两条设硬性交互轮次上限比如最多允许10轮工具调用超过强制收尾并输出“当前已完成部分结果未完成原因”。引入“完成度自评”机制每轮结束后让模型分析“当前完成百分比是多少下一步是否需要继续”。这个方法能有效压制模型无意义循环因为自评会迫使模型自我审视。这两个方法不冲突建议同时使用。4.3 Agent编造数据怎么办幻觉问题是Agent落地最大的“信任杀手”。我总结了三层防御数据源头限制在提示词中限制“只能使用工具返回的数据不得从内部知识库盲猜具体数值”。结果格式约束涉及具体数值的输出强制以结构化字段如JSON输出并标记数据来源字段。事后验真循环关键结论生成后调用一次代码解释器或计算工具比对数值是否合理。这三层下来编造数据的概率能显著下降但无法做到100%。对于涉及军令状级别严肃业务财报、医疗建议人类审核仍是必须的。4.4 技能扩展多Agent协作时的技能边界最后补一个很多人会忽视的技能点——多Agent协作时的“能力边界声明”。在做复杂项目时往往需要多个Agent分工。每个Agent只负责一个子模块但这引来了新问题A Agent不知道B Agent能做什么导致重复劳动或者互相推诿。我的解决办法是在每个Agent的系统提示词里加入“我能做什么、我不能做什么、什么情况下应该转交其他Agent”这三段声明。这样Agent之间协作时调用和交接会顺畅很多。这个经验我在实际项目里验证过多次效果显著。事后复盘时我个人最大的体会是Agent开发其实不是算法问题而是工程问题。你不会觉得哪里有高深莫测的技术门槛但就是有一堆“没想到”和“没兜住”的坑。把技能体系当成工程规范来做用方法论约束模型的自由度用评测集防回归用日志慢慢打磨——这套路稳扎稳打比追求“花哨玩法”可靠得多。如果要从这套agent-skills里挑一个最容易出效果、也最难掌握的技能重点投入我个人建议优先练好“上下文管理”。这玩意一旦做好了很多其他问题会随之消散。模型有了清晰的上下文视野工具调用会更准自我纠错会更顺输出质量自然上一个台阶。最后再分享一个小技巧给Agent的每次关键操作都加上结构化日志。这在调试和排查时是你的“病历本”不知道问题出在哪的时候翻日志永远比猜答案快。用这个方法排查几次问题后你就会发现那些看似玄学的问题基本都是可推理、可修复的。
1. 项目缘起与整体思路1.1 我为什么开始整理这套“Agent技能树”做AI Agent开发这一年多我最大的感触是真正卡住大多数人的不是模型能力而是“怎么把模型能力落成一个能稳定干活的Agent”。市面上教程很多但大多只教你怎么调API、怎么写一个ReAct循环。可实际项目中你会发现Agent经常“看起来聪明干起活来却像个实习生”——让它查资料它给你编让它调工具它参数传错让它多步推理它中途跑偏。问题出在哪出在缺少一套系统化的“技能体系”。我整理这套agent-skills的核心目标就是想解决三个具体问题如何让Agent稳定地完成多步骤任务而不是偶尔成功、经常翻车。如何让Agent高效地“使用工具”而不是拿到工具不知道怎么下手。如何让Agent具备“自我纠错”和“边界感知”能力而不是无脑执行搞出大问题。这三件事恰恰是Agent从“demo玩具”走向“生产工具”的必经之路。1.2 这套技能体系解决什么问题先说清楚这套agent-skills不是某个具体框架的教程它是一套方法论实操模式的组合。你可以把它理解为“Agent开发者的能力地图”——帮助你快速定位当前项目卡在哪该补哪块技能。我整理的内容适合以下几类人刚入门Agent开发被各种概念ReAct、Tool Calling、RAG、Memory绕晕的新手。已经能跑通简单Demo但一做复杂任务就稳定性和效果差的老手。需要在业务中落地Agent但团队里缺乏可复用的模式模板的工程负责人。它不像论文那样抽象也不像代码注释那样琐碎。它更像是一个“经验清单”——把我在实际项目里踩过的坑、验证过的方案、沉淀下来的模板按技能维度梳理出来。2. 核心技能维度拆解2.1 技能一任务拆解与规划能力Agent和普通AI对话最大区别在于对话只需“回应”Agent必须“干活”。干活就意味着任务拆解。这个技能我拆成三层第一层目标理解层。模型能否从用户的模糊需求中提取出可执行的目标。比如用户说“帮我整理一份市场调研报告”好的Agent应该在执行前拆出调研对象是谁报告给谁看篇幅要求数据来源需要哪些图表第二层步骤规划层。拆解成一个有序的步骤流程图。比如“先收集数据、再清洗数据、然后生成图表、最后撰写结论”。这一步看起来简单但实际极容易出错。模型经常跳过关键步骤或者步骤之间逻辑不连贯。第三层动态调整层。真实执行过程中Agent必须允许自己“改变计划”。比如原计划第一步是抓某个网站结果该网站改版了Agent理应能识别这个异常调整方案而不是死磕到底或者直接放弃。实际操作中规划层最实用的一个技巧是倒推法先让模型自己回答“这个任务的最终产出物是什么”然后再问“要得到这个产出前一步必须完成什么”。这样一步步倒推得到的步骤列表往往比正向思考更加严谨。我实测过同样的模型和Prompt用倒推法写出的执行计划出错率能降低30%左右。2.2 技能二工具调用与API交互Agent技能的第二个核心是工具调用。这一块我不想讲概念直接说几个我踩过的坑。坑一工具描述写不清。Agent调用工具靠的是模型的语义理解。如果你的工具描述写得含糊模型很容易选错工具。举个例子你有两个工具一个“获取当日天气”一个“获取历史天气”。如果描述不够明确Agent隔三差五就选错。解决办法是在描述里写明调用条件和典型场景比如“当用户询问今日天气时使用当用户询问过去某天天气时使用另一个”。坑二参数映射错位。模型从用户话语里抽取参数要做到准确实属不易。比如用户说“帮我订明天下午三点的会议室”你定义的参数是date_time要求ISO格式模型往往直接输出“明天 15:00”这种人类写法。解决办法是在工具定义里写清楚参数格式的示例值不要只写类型和描述。坑三忽略工具的执行状态码。很多Agent实现只关注“工具返回了什么”不关心工具本身报了什么错。这样导致的结果是工具明明返回了错误信息Agent却还在硬着头皮处理错误结果最后产出垃圾输出。我在项目中强制约束任何工具调用都要检查执行状态出错时先返回错误信号让模型介入决策。我还有一个经验工具调用的成功率很大程度取决于你是不是做了“工具调用演练”。上线前用一组典型场景去测试Agent的选工具和传参能力把失败的案例收集起来针对性地修改工具描述或少量样本示例。这一套循环做两三轮工具调用的准确率就能达到生产可用级别。2.3 技能三上下文管理与记忆机制Context是Agent最值钱的资源也是最容易浪费的资源。我见过太多失败的Agent案例根本原因不是模型不够聪明而是把上下文窗口塞满了无效信息导致模型“该记的记不住不该记的全记住了”。我总结了一套上下文分层的办法核心指令层永远在Top系统提示词、安全约束、任务目标。这部分不能被对话内容稀释。持久记忆层用户的偏好、历史关键结论、长期事实。这部分在每次对话开始时注入。短期工作区当前任务的中间产出比如已抓取的数据表格、当前执行计划。这部分可以动态增删随着任务推进不断覆盖。临时参考层模型检索到的外部资料、临时搜索结果。这部分要用摘要的方式存放尽量避免把长文档原封不动塞进去。我常用的一个做法是每次工具调用结束后先让模型用两三句话总结“这次调用获得了什么有效信息”再放到上下文里。这样做看起来多了一步模型调用但带来的收益非常明显——后续的推理质量大幅提升因为模型不用在原始返回的一堆JSON里翻找关键信息。2.4 技能四自我纠错与反思机制Agent最让人头疼的一点做错了还不自知一本正经地给出错误答案。所以我专门把这部分单列成一个技能维度。自我纠错机制的核心不是让模型“思考得更认真”而是给模型提供“验证缺口”。什么叫验证缺口就是让模型在给出答案之前先自问三个问题我的结论有事实依据吗依据来自哪里我的执行步骤中有没有哪一步是不可靠的有没有我忽略的边界情况具体到实现上我推荐一种“双层反射”模式第一层执行完任务后模型先自己Review一遍输出检查是否满足任务要求格式是否正确逻辑是否自洽。第二层如果任务涉及数字或事实强制调用一个外部工具比如计算器、搜索结果、数据库查询去验证关键结论。这套机制看起来会多消耗一些Token但对于结果可靠性要求高的场景比如代码生成、数据分析、金融报告这笔开销是值得的。2.5 技能五多模态与多格式处理现阶段的Agent开发几乎不可能绕开多模态和多种文件格式的处理。纯文本场景反而越来越少见。实际项目里用户传来的可能是PDF、Excel表格、图片截图、甚至一段录音。针对这个维度我最想强调的一点是不要试图让大模型直接处理原始文件先把文件转成统一的结构化中间格式。比如PDF文件先用解析工具转成Markdown或者纯文本再交给Agent。如果是Excel先转成CSV并且把列名、单位说明好。如果是图片先做OCR提取文字再做视觉理解。这一步“前置结构化”可以大幅度减少模型出错概率因为大模型处理规范化文本的性能远好于处理乱七八糟的原始文件。3. 实操过程与核心实现细节3.1 从零搭建一个具备基础技能的Agent这部分我用一个具体案例来演示搭建一个“会议纪要整理行动项追踪”的Agent。这个场景足够简单但又覆盖了任务拆解、工具调用、上下文管理和自我纠错多个技能点。第一步明确工具集。会议录音转文字工具ASR。文本摘要工具。日历API用于查询与会者日程判断行动项截止时间的合理性。文档存储工具用于保存最终纪要。第二步设计系统提示词。我强调“角色能力边界工作流程”三段式你是一名会议纪要助手。你的工作是把会议录音转换为结构化纪要并提取行动项。 你只处理与会议相关的信息对于不确定的内容必须标注“待确认”不可编造。 工作流程先转写再分段然后提取议题和结论最后生成行动项并保存。这段提示词里最关键的其实是“不可编造”和“待确认”。这能极大减少模型输出幻觉内容的风险。第三步写工具调用逻辑。核心代码如下这里用类Python伪代码表达def run_agent(transcript_file): # 1. 转写阶段 raw_text asr_tool.transcribe(transcript_file) # 2. 分段摘要阶段注意用分段法而不是全文摘要 segments split_by_topic(raw_text) summaries [summarizer.summarize(seg) for seg in segments] # 3. 提取行动项阶段 action_items extract_action_items(summaries) # 4. 校验动作项是否包含负责人、截止时间、具体任务 for item in action_items: if not item.get(assignee) or not item.get(deadline): flagged 待确认 # 5. 保存 doc_store.save({summary: summaries, action_items: action_items}) return action_items注意我在第4步用了一个“校验”环节这就是前面说的自我纠错机制的在真实场景里的落地实现。不要相信模型一次性提取的完整度强制加一道“字段是否齐全”的程序化校验。3.2 调试技能时的关键参数配置调试Agent技能的“手感”和调传统机器学习模型完全不同。我整理了一套核心参数清单以及我常用的初始值配置项作用建议初始值调试方向temperature输出随机性0.2事实精准场景调低创意场景调高top_p核采样0.9一般不动max_tokens单次生成上限根据任务定任务复杂时宁可拆步骤工具调用阈值触发工具调用的置信度0.6过低则频繁误调过高则漏调反思触发条件何时做二次校验涉及数字/日期/API视业务风险程度调整这里特别想提醒一个经验不要一上来就调temperature。多数Agent效果差不是随机性问题而是提示词或工具定义有问题。我见过团队调了一下午temperature最后发现是工具描述里参数单位写错了。优先排查结构性错误再调随机性参数。3.3 用评测集“打磨”技能的实操方法技能体系的建立是动态迭代的你需要一套评测集来持续验证和回归。我的做法是准备20-30个典型任务覆盖正常场景、边界场景、错误输入场景。比如会议纪要这个场景正常一段40分钟的销售例会录音。边界录音只有5分钟且只有一个人说话。错误输入上传的是一段音乐而不是人声。然后跑一遍全流程记录每一类场景的表现。正常的要稳定成功边界的要“不崩溃”错误输入的要“拒绝执行”。把失败案例加入评测集的“回归清单”每次修改后重新跑一遍确保不引入新的问题。这套流程做完一遍后你的Agent技能基本就能从“demo级”跨入“可复用级”。4. 常见问题与排查思路实录4.1 Agent“答非所问”怎么排查状态表现为Agent没有报错但输出内容和用户问题对不上。我建议排查顺序如下第一查上下文占用。很多情况下Agent把大量历史内容堆在上下文中导致注意力分散。查看发送给模型的Prompt里实际包含多少历史内容先做裁剪。我经常发现某些会话历史占了上下文的80%模型被历史信息“带跑”了。第二查工具返回结果。有些工具返回的内容格式极差比如全拼接的长JSON、没处理的Markdown符号。模型接收后部分内容变成了噪声。把工具输出做summary和结构化往往能解决一半“答非所问”。第三查指令冲突。系统提示词里的要求和用户当前的问题存在隐性互斥。比如系统提示“只回答与会议相关的内容”用户问“现在的天气”模型就很有可能陷入一种“不知道该不该回答”的纠结。这一类冲突日志中通常不显示需要人工读Prompt日志才能发现。4.2 Agent“绕圈子”不结束任务怎么办这个问题的本质是循环缺少终止条件。Agent不断地重新规划、重新尝试就是不输出最终答案。我的解决办法有两条设硬性交互轮次上限比如最多允许10轮工具调用超过强制收尾并输出“当前已完成部分结果未完成原因”。引入“完成度自评”机制每轮结束后让模型分析“当前完成百分比是多少下一步是否需要继续”。这个方法能有效压制模型无意义循环因为自评会迫使模型自我审视。这两个方法不冲突建议同时使用。4.3 Agent编造数据怎么办幻觉问题是Agent落地最大的“信任杀手”。我总结了三层防御数据源头限制在提示词中限制“只能使用工具返回的数据不得从内部知识库盲猜具体数值”。结果格式约束涉及具体数值的输出强制以结构化字段如JSON输出并标记数据来源字段。事后验真循环关键结论生成后调用一次代码解释器或计算工具比对数值是否合理。这三层下来编造数据的概率能显著下降但无法做到100%。对于涉及军令状级别严肃业务财报、医疗建议人类审核仍是必须的。4.4 技能扩展多Agent协作时的技能边界最后补一个很多人会忽视的技能点——多Agent协作时的“能力边界声明”。在做复杂项目时往往需要多个Agent分工。每个Agent只负责一个子模块但这引来了新问题A Agent不知道B Agent能做什么导致重复劳动或者互相推诿。我的解决办法是在每个Agent的系统提示词里加入“我能做什么、我不能做什么、什么情况下应该转交其他Agent”这三段声明。这样Agent之间协作时调用和交接会顺畅很多。这个经验我在实际项目里验证过多次效果显著。事后复盘时我个人最大的体会是Agent开发其实不是算法问题而是工程问题。你不会觉得哪里有高深莫测的技术门槛但就是有一堆“没想到”和“没兜住”的坑。把技能体系当成工程规范来做用方法论约束模型的自由度用评测集防回归用日志慢慢打磨——这套路稳扎稳打比追求“花哨玩法”可靠得多。如果要从这套agent-skills里挑一个最容易出效果、也最难掌握的技能重点投入我个人建议优先练好“上下文管理”。这玩意一旦做好了很多其他问题会随之消散。模型有了清晰的上下文视野工具调用会更准自我纠错会更顺输出质量自然上一个台阶。最后再分享一个小技巧给Agent的每次关键操作都加上结构化日志。这在调试和排查时是你的“病历本”不知道问题出在哪的时候翻日志永远比猜答案快。用这个方法排查几次问题后你就会发现那些看似玄学的问题基本都是可推理、可修复的。
