做 AI agent 开发的人绕不开一个问题这个方向到底需要哪些技能才算够我最近重新把整套东西梳理了一遍发现不少同学把 agent 开发理解成“会调模型接口就行”结果真正上手以后才发现模型只是最小的一块。工具调用不稳定、上下文越聊越乱、批量任务跑到一半就挂、线上报错定位不了这些才是日常。下面按“做 agent 真正用得上的技能”来拆适合想入门 agent 开发的同学也适合已经在做 agent 项目但觉得心里没底的人。最值得先想清楚的结论是agent 是一个完整系统不是一次对话真正拉开差距的往往不是模型选择而是工具调用、记忆管理、任务编排、异常处理和评测反馈这些工程能力。1. 先搞清楚“agent 技能”到底指什么1.1 skill、agent、harness 别混着用讨论 agent 开发技能之前先把概念对齐。现在很多资料把 skill、tool、agent、harness 混着讲导致学习者经常卡在名词上。做项目时这些概念分工其实非常明确skill 或 toolagent 能调用的一项具体能力比如读文件、查数据库、执行 SQL、调内部 API。它通常是一段代码加一份参数说明。agent负责决策的逻辑层。它根据用户目标和当前上下文决定调哪个 skill、按什么顺序调、什么时候结束。harness宿主或框架把 agent 和 skill 之间的调度、上下文注入、回退重试、日志记录这些脏活统一包起来的外壳。线上部署 agent 时实际跑起来的往往是这个外壳。所以“agent 开发需要哪些技能”这个问题翻译成工程语言就是四件事能不能让模型按预期决策能不能让 agent 稳定调用外部能力能不能控制整个执行过程以及出问题时能不能快速定位修复。这四个问题基本覆盖了 agent 开发的核心工作范围。1.2 基础技能和进阶技能的分界我习惯把技能分成两层。基础层是“能跑通”会写提示词会调模型接口会定义一个工具函数能在一次多轮对话里完成一个简单任务。进阶层是“能控住”任务拆解准确工具调用参数不出错上下文不爆失败能自动重试批量任务不丢不重线上出问题能靠日志定位。很多人卡在这两层中间不是模型能力不够而是工程能力没跟上。比如单条任务跑得不错一进批量就乱套或者 Demo 能演示一接真实输入就崩。这类问题几乎每次都出在输入输出设计、异常处理和状态管理上。能力项基础阶段进阶阶段模型调用能发起请求并拿到文本能处理多轮循环中的结构化输出和异常工具调用能调用一个写死的函数能根据参数 schema 动态选择工具并校验返回值记忆管理会把历史直接拼接进 Prompt能做摘要、检索和持久化任务编排单次“任务-回答”多步规划、条件分支、失败回退、终止判断排查能力会看报错文本能从日志还原完整执行链路2. 开发 agent 前必须掌握的底层能力2.1 模型调用与提示词工程这一块是地基。agent 里的模型调用和普通聊天不一样它不是在对话而是在一个多轮循环里反复执行“理解输入、决定下一步、产出结果”。所以提示词工程的核心目标不是让回答更好看而是让每一步的输出都可解析、可判断、可依赖。要掌握的具体能力包括system prompt 怎么设计角色、约束、输出格式怎么写才能让模型稳定遵守结构化输出怎么拿也就是要求模型返回 JSON 或固定字段并在解析失败时做重试few-shot 样例怎么给样例不是越多越好而是要覆盖边界情况温度和超时参数怎么设agent 场景通常希望输出更稳定温度不要随手拉高。为什么这些重要因为 agent 的后续逻辑要靠模型输出来驱动。如果模型返回一段带解释文字的 JSON或者字段名偶尔变一下后面的工具调用就会失败。这时候不管模型多强都没用。2.2 工具调用与函数定义agent 和普通问答相比最大的增量就是“能做事”而做事靠工具。工具定义的关键反而不是函数本身而是参数 schema。模型是根据函数名、参数描述和示例来决定要不要调用、该填什么参数的。描述写得含糊模型就会在不该调用的地方乱调或者在需要传参时漏参。工具返回值的格式也很重要。返回结果要结构化模型才能解析并使用。比如查数据库返回的不应该是一段自然语言而应该是字段明确的 JSON。返回字段如果不稳定模型下一步就没法决策。我一般会从小工具开始练比如查时间、查天气、做计算。先确认模型能在正确时机调用再逐步加复杂工具。不要一上来就挂一堆工具工具多了以后模型选错的概率会明显上升。2.3 记忆、上下文与状态管理上下文窗口再大也是有限的agent 跑多轮以后不可能把历史全部塞进去。记忆这块要分几层来看。短期记忆解决“这次任务里已经做了什么”通常用对话摘要或关键状态维护长期记忆解决“用户的偏好或历史知识怎么复用”一般靠向量检索加数据库持久化状态管理解决“任务现在进行到哪一步”这对多步骤任务尤其重要。为什么状态管理容易被低估因为很多 agent 不是一次问完的而是连续执行多步。每一步都要知道当前进度、已完成步骤、剩余待办。如果状态只存在于模型上下文的文字描述里上下文一旦被截断任务进度就丢了。更稳妥的做法是把关键状态单独存一份每一步执行完都更新一次。2.4 任务编排、循环与控制agent 的核心循环是规划、调用工具、观察结果、再规划直到完成任务或者达到终止条件。这个循环听起来简单实际要控制的东西不少。第一是最大步数。没有上限的 agent 会死循环消耗大量 token 还停不下来。第二是条件分支。模型不是每一步都要调工具有些情况下应该直接回答或者直接请求人工介入。第三是终止条件。成功、失败、超时、用户打断这几种结束方式都要能识别。第四是错误回退。工具调用失败以后是重试、换一个工具还是把问题抛给用户都要有明确逻辑。这一层是 agent 和普通问答最大的区别。普通问答只要模型返回一段话就算完成agent 则要保证整个执行过程可控、可终止、可解释。3. 从框架选型到落地不同阶段需要补哪些技能3.1 入门阶段用成熟框架跑通最小 Demo现在 agent 框架非常多常见的像 LangChain、LangGraph、AutoGen、微软 Agent Framework各家模型厂商也推出了自己的 Agent SDK。它们的抽象不太一样但核心概念基本一致模型、工具、编排、记忆。我建议入门阶段不要纠结选哪个框架先挑一个文档全、例子多的跑通一个带工具调用的最小 agent。这里“跑通”不只是不报错而是满足四个条件能正常启动一个简单任务能完成日志里能看到每一步你知道改哪一行会影响行为。这四个条件都满足说明你对这个框架的基本运行路径已经有感觉了。重点是先跑单条任务不要同时开批量。单条任务稳定之后再谈并发和队列。很多人一上来就把并发拉满结果报错、乱序、输出丢失混在一起最后连问题出在哪一层都分不清。3.2 进阶阶段批量任务、失败重试与断点续跑真实项目里很少只跑一条输入更多的是批量处理文件、数据或用户请求。批量任务和单条任务对技能的要求完全不同。单任务能跑通完全不等于批量能稳定。批量阶段要补的技能包括输入管理任务从文件、数据库还是队列里读。输出管理结果怎么命名怎么和输入对应怎么去重。失败处理单条失败是重试还是跳过重试几次间隔多久。断点续跑任务跑到一半程序挂了重启后能不能跳过已完成的。限流模型接口有配额批量任务的请求速率必须控制否则会被限流。经验上我会建议批量先跑小样本。先跑十条确认输出格式、日志和失败处理都符合预期再跑全量。不要一上来就开最大并发。并发一高报错一多最后连哪些任务成功、哪些失败都分不清。3.3 生产阶段稳定性、观测、成本与安全能批量跑之后离上线还有一段路这段路主要补四类技能。稳定性agent 是多轮执行任何一轮失败都可能拖垮整个任务。所以要设计重试、回退和兜底逻辑。观测日志要记录每轮输入输出、工具调用前后的参数和返回值、消耗的 token 数和耗时。没有这些细节线上报错根本没法排查。成本token 消耗在 agent 场景下很容易超预算。多轮调用、失败重试、上下文累积都会显著增加成本。要给每次任务设预算上限超了就终止或者降级。安全工具越强误操作风险越大。最小权限、敏感操作人工确认、操作审计这三件事要提前想。注意不要因为框架支持某种能力就直接在生产环境放开所有工具。先评估工具能做什么、会造成什么影响再决定给 agent 多少权限。4. 最容易被低估的几类技能4.1 输入输出设计与格式校验agent 挂在格式上的概率远高于挂在模型理解力上的概率。输入侧常见的问题是字段缺失、文本编码不对、文件路径不存在、输入太长被截断输出侧常见的问题是模型返回了非 JSON 文本、字段名不稳定、嵌套结构解析失败。我自己的排查顺序是先看输入输出结构再看模型行为。因为大部分“agent 执行被终止”的报错最后定位到的都是格式问题而不是模型不会做。最直接的做法是在工具入口做 schema 校验在模型输出解析失败时加一次修复调用而不是直接抛异常结束整个任务。输入输出这层做好很多看起来玄学的问题都会消失。4.2 日志、排查与可观测性“agent execution terminated due to error”这种报错信息只给了一句话单独看根本定位不了问题。正确的排查顺序应该是先判断是在哪一步挂的规划阶段、工具调用阶段还是结果解析阶段。再看这一步的输入输出提示词、工具参数、返回结果。再看环境和资源依赖版本、权限、接口配额、超时设置。最后才考虑调参数最大步数、重试次数、温度。这里有个容易犯的错一报错就换模型。很多事故的根因根本不在模型换模型只是让问题换一种方式出现。先看日志再动配置这是排查的基本纪律。4.3 安全与权限边界让 agent 调用 API、执行代码、修改数据库之前先想清楚一个问题如果它理解错了会造成什么后果。agent 的决策是概率性的再强的模型也可能在某个边界输入上做出错误调用。安全这块要做的不是阻止 agent 做事而是把风险控制住。最小权限原则每个工具只给完成职责所需的最低权限敏感操作人工确认删除、转账、发布这类动作不能由 agent 自动完成操作审计记录谁在什么时间让 agent 执行了什么操作。这些能力在 Demo 阶段可以不管但一旦接入真实系统就是硬要求。4.4 效果评测与回归测试没有评测agent 就没法迭代。主观感觉“好像变聪明了”不算数因为 agent 是多步系统改一个提示词可能影响后面所有步骤。做法是建一个固定测试集20 到 50 条覆盖主要场景的样例。每次改动跑一遍全量测试对比任务完成率、工具调用正确率、输出合法率、平均耗时和 token 消耗。失败的样例要留下来形成回归集防止改了 A 问题又弄坏 B 场景。评测集不用一开始就很大但要稳定要能反映真实用户输入的样子。5. agent 学习路线分阶段怎么练5.1 第一阶段跑通一个最小 agent第一阶段的目标很窄完成“用户提问、模型决定调用工具、工具返回结果、模型总结答案”这个闭环就算过。练什么一个真实的工具函数比如查时间或查天气要求模型返回结构化 JSON在多轮对话里保持任务目标不跑偏。验收标准建议量化连续跑十个不同的输入至少八个能正确完成并且每一次失败都能说出原因。如果说不出来说明日志还不够完整先补日志不要急着继续加功能。5.2 第二阶段加工具、加记忆、加批量第二阶段开始接触 agent 的真实复杂度。练三件事。一是多工具调度三到五个工具之间模型能正确选择该用哪个。二是失败重试工具调用失败后能自动走兜底逻辑而不是让整个任务直接终止。三是记忆和批量给 agent 加短期记忆和长期存储然后批量跑五十条输入统计成功率、耗时和失败原因分布。这一阶段最容易暴露的问题就是单任务和批量的差距。批量跑完以后要能回答三个问题哪些任务成功了哪些失败了失败的具体原因是什么。答不上来时优先补日志而不是继续调参数。5.3 第三阶段生产化与协作第三阶段练的是“能不能回答清楚边界”。你要能说明白这个 agent 在什么条件下可靠、什么条件下不可靠什么时候需要人工介入成本和延迟在什么范围权限是怎么控制的。到这个阶段技能就不只是代码能力了还包括需求拆解、评测设计和跨系统协作。你会开始理解为什么有的团队会自研编排层而不是完全依赖框架也会理解为什么生产环境的 agent 往往比 Demo 版本保守得多。这很正常因为生产环境的第一目标是别出事其次才是能力上限。6. 常见误区和面试里的高频判断6.1 容易踩的坑第一个误区是“模型越强agent 越不需要工程”。模型强只解决决策准确率解决不了编排、异常、格式和权限问题。模型再强工具返回格式不对照样失败。第二个误区是“框架越省事越好”。框架省的是起步时间不是维护成本。越到后期越需要理解框架底层是怎么调度的否则出了问题只能干瞪眼连从哪里开始在日志里查都不知道。第三个误区是“Demo 跑通就算完成”。Demo 只验证了单任务在理想输入下能走通批量、并发、日志、权限这些生产要素全都没验证。Demo 和生产的差距远比大多数人想象的大。第四个误区是“报错就换模型”。很多问题出现在输入输出设计、工具参数和权限上。换模型等于把真正的 bug 藏起来等下一次换个场景再爆发。误区实际现象正确做法模型越强越省事强模型也会在工具参数上出错先把工具 schema 和输入输出设计做扎实框架越省事越好后期出问题无法定位理解框架的调度和日志路径Demo 跑通即完成批量、并发一上就崩按小样本逐步验证生产要素报错就换模型根因在格式或权限按输入、环境、参数顺序排查6.2 面试或评审时怎么答“需要哪些技能”现在 agent 方向的面试题很多市面上的“agent 八股”也很多。我的建议是不要背名词而是按“决策、行动、状态、控制、观测、安全”这六层来组织回答。决策层讲提示词和结构化输出行动层讲工具调用和 schema 设计状态层讲记忆和进度管理控制层讲编排、循环和终止条件观测层讲日志和评测安全层讲权限和审计。每讲一层都要配一个自己做过的具体案例哪怕是一个很小的工具调用案例都行。最后主动提一句边界什么场景不适合用 agent什么时候必须人工确认。这种回答方式比流利背出二十个框架名词有用得多。评审判断一个人是不是真的做过 agent 项目通常就看两点能不能讲清楚一次失败是怎么排查出来的以及能不能说清楚这个方案在什么情况下会失效。我自己带项目时常用的判断标准只有一个这个人能不能把一个 agent 从“跑一次成功”带到“连续跑一百次大部分成功失败还能讲清楚原因”。能说明技能是真实的不能说明还停留在 Demo 阶段。这也是我认为 agent 开发最值得投入的方向——不是把单个能力做得多花哨而是把整个执行过程控制住让系统在真实输入面前保持稳定。