AI Agent 这个词在过去一年里被反复提及但真正动手搭过一套能跑起来的 Agent 系统的人都知道从能对话到能干活之间隔着一整套工程决策。我前后参与过几个 Agent 项目从最初用几十行代码拼一个 ReAct 循环到后来处理工具调用的参数校验、上下文爆炸、循环失控这些真实问题踩过的坑比看过的论文多得多。这篇内容想做的事情很直接把 Agent 从概念拆到工程落地用七个核心要素讲清楚它由什么构成再用七个决策点讲清楚搭建时每一步该怎么选、为什么这么选。不管你是刚接触 Agent 开发的新手还是已经写过 Demo 但卡在稳定性上的开发者都能从中找到可以直接参考的判断依据。关键词覆盖 AI Agent、LLM、工具调用、循环机制、Agent 架构、Agent 记忆、Agent 安全这些核心概念全文围绕工程实现展开不空谈趋势。1. 先把 Agent 和普通 LLM 调用区分开很多人第一次接触 Agent 时会有一个误解觉得给 LLM 加个系统提示词让它扮演一个助手这就是 Agent 了。实际上这两者的差别类似于计算器和会自己找数据、自己算、自己检查结果的分析师之间的差别。理解这个差别是后面所有工程决策的前提。1.1 单次调用与循环执行的本质差异普通 LLM 调用的模式是输入一段文本模型输出一段文本结束。整个过程是一次性的模型没有机会根据输出结果去调整下一步动作。你问它北京今天天气怎么样它要么基于训练数据编一个要么告诉你它不知道。它不会主动去调一个天气接口拿到结果之后再决定要不要提醒你带伞。Agent 的核心变化在于引入了循环机制。模型输出不再只是给用户看的文本而可能是一个动作指令——比如调用某个工具、查询某个数据源、写入某个文件。系统执行这个动作后把结果再喂回给模型模型基于新信息决定下一步。这个思考-行动-观察-再思考的循环才是 Agent 区别于单次调用的根本。我用一个具体的对比来说明。假设任务是帮我查一下公司上季度营收和去年同期比一下然后写一段分析。普通 LLM 调用会直接生成一段看起来像分析的文字但数字大概率是编的因为它没有真实数据。而一个配置了数据库查询工具和分析工具的 Agent会先调用查询工具拿到两个季度的真实数字然后调用计算工具做同比最后基于真实结果生成分析。中间每一步的输出都会影响下一步的决策。这个差异带来的工程复杂度是数量级的。单次调用你只需要关心提示词和输出格式Agent 你需要关心工具定义、参数校验、循环终止条件、错误处理、上下文管理、成本控制。这也是为什么很多人写 Demo 很顺一上生产就各种问题。1.2 为什么能调用工具不等于会做决策另一个常见误解是只要模型能调用工具它就是一个 Agent 了。工具调用确实是 Agent 的必要能力但会调用和会决策是两回事。我见过不少实现把一堆工具的定义塞给模型然后期望模型自己规划出正确的调用顺序。结果模型要么反复调用同一个工具要么在应该停止的时候继续调用要么选了一个完全不相关的工具。这不是模型能力不够而是工程上没有给模型足够的决策支撑。真正的决策能力来自几个方面清晰的工具描述让模型知道每个工具什么时候该用合理的循环控制让模型知道什么时候该停必要的状态管理让模型知道已经做了什么、还差什么。这些都不是模型自带的而是工程层面设计出来的。举个实际例子。我在一个文档处理 Agent 里定义了读取文档提取段落生成摘要保存结果四个工具。最初版本模型经常在生成摘要后又去调用读取文档陷入循环。后来我在系统提示里明确写了摘要生成后任务即完成不需要再次读取同时在循环控制里加了连续两次调用相同工具则强制终止的规则问题才解决。这说明工具调用的正确性很大程度上依赖工程约束而不是模型自觉。2. 解构 Agent 的七个核心要素把 Agent 拆开来看不管用什么框架、什么语言实现本质上都包含七个要素。理解这七个要素你就有了分析任何 Agent 系统的框架也能在搭建时知道哪些地方不能省。2.1 模型不只是选个大的就行模型是 Agent 的大脑负责理解任务、规划步骤、生成工具调用参数、判断是否完成。选模型时最常见的误区是越大越好。实际上 Agent 场景对模型的要求和普通对话不一样。Agent 需要模型具备几个特定能力结构化输出能力能稳定输出符合格式的工具调用请求、指令遵循能力能严格遵守系统提示里的约束、多步推理能力能根据中间结果调整计划。有些模型在对话上表现很好但在结构化输出上经常跑偏这种就不适合做 Agent 的主模型。我的经验是主模型优先选工具调用能力经过专门优化的哪怕参数量小一些。因为 Agent 的循环里模型要被调用很多次每次调用的稳定性和成本都会被放大。一个 70B 的模型如果每次都能正确输出工具调用比一个 400B 但十次里有三次格式错误的模型更实用。另外要考虑成本和延迟的平衡。Agent 一次任务可能触发五到十次模型调用如果每次调用都很慢很贵用户体验和运营成本都会出问题。实际项目里我经常采用分层策略主循环用能力强的模型一些简单的判断比如这个结果是否为空用轻量模型处理。2.2 工具Agent 的手和脚工具是 Agent 与外部世界交互的接口。没有工具Agent 就只是一个会说话的模型有了工具它才能查数据、写文件、发请求、操作软件。定义工具时最关键的不是功能多而是描述清晰。模型选择工具完全依赖你给的描述。描述里要包含这个工具做什么、什么时候用、参数是什么含义、返回什么。我见过太多工具描述写得含糊导致模型乱调用的情况。一个反例是工具描述只写查询数据。模型看到这个描述完全不知道查什么数据、什么场景下该用。正面的写法是根据用户ID查询该用户最近30天的订单记录返回订单号、金额、状态列表。当需要了解用户消费情况时使用。工具的数量也要控制。我建议单个 Agent 的工具数量控制在 10 到 20 个之间。太少了能力不足太多了模型选择困难而且每次调用都要把全部工具定义塞进上下文token 消耗会很大。如果确实需要很多工具可以考虑分组或者用路由机制先判断任务类型再加载对应工具集。2.3 记忆短期和长期要分开设计Agent 的记忆分两类工程上必须分开处理。短期记忆是当前任务执行过程中的上下文包括用户输入、每一轮的模型输出、工具调用结果。这部分通常直接放在对话历史里随循环不断增长。问题是它会迅速膨胀——一次任务十轮循环每轮工具返回几千字很快就超出上下文窗口。长期记忆是跨任务、跨会话需要保留的信息比如用户偏好、历史交互摘要、领域知识。这部分需要外部存储通常是向量数据库或结构化数据库在需要时检索注入。短期记忆的处理是工程难点。我的做法是工具返回结果先做截断或摘要只保留关键信息再放入上下文对于很长的历史定期做压缩把前面的多轮交互总结成一段简短描述。这样既保留了必要信息又控制了 token 增长。长期记忆的关键是检索时机。不是每次都要检索而是在任务开始时根据用户输入判断是否需要调取历史信息。检索回来的内容也要控制数量通常 top 3 到 top 5 就够了太多反而干扰模型判断。2.4 规划让模型知道先做什么后做什么规划能力决定 Agent 能不能处理复杂任务。简单任务模型可以边做边想复杂任务如果不先规划很容易做到一半发现方向错了。规划有两种实现方式。一种是显式规划在任务开始时让模型先输出一个步骤列表然后按列表执行。这种方式可控性强适合流程相对固定的任务。另一种是隐式规划不单独规划模型在每轮循环里自己决定下一步。这种方式灵活适合探索性任务但容易跑偏。实际项目里我倾向于混合先让模型输出一个粗略的计划三到五步执行过程中允许根据实际情况调整。这样既有方向感又保留了灵活性。计划本身也作为上下文的一部分让模型在每轮都能看到我原本打算做什么减少偏离。2.5 循环控制Agent 的心跳循环控制是 Agent 工程里最容易被低估的部分。它决定了 Agent 什么时候继续、什么时候停止、异常时怎么办。最基本的循环是模型输出 - 如果有工具调用则执行 - 结果回填 - 再次调用模型 - 直到模型输出最终答案。但实际实现里要处理的情况多得多模型连续调用同一个工具怎么办工具执行报错怎么办循环次数超过预期怎么办token 消耗超过预算怎么办我的做法是设置多重终止条件模型明确表示完成、达到最大循环次数、连续多次无有效进展、token 预算耗尽。任何一个触发都终止循环并给出相应的处理。最大循环次数我一般设 10 到 15具体看任务复杂度。这个数字不是拍脑袋而是根据实际任务的平均循环次数上浮 50% 得出的。2.6 工具调用的参数处理最容易被忽视的环节模型生成的工具调用参数经常有问题类型不对、缺字段、值超出范围、格式不符合要求。如果不做校验直接执行轻则报错重则产生副作用比如删错了数据。参数处理要做三件事校验检查必填字段、类型、范围、修正能自动修的自动修比如字符串数字转数字、反馈不能修的把错误信息返回给模型让它重新生成。我强烈建议工具的参数校验用 schema 定义而不是手写 if-else。schema 既能用于校验也能作为工具描述的一部分给模型看一举两得。校验失败时返回的错误信息要具体告诉模型哪个字段错了、期望什么格式而不是笼统的参数错误。2.7 安全边界Agent 能做什么不能做什么Agent 有了工具调用能力就意味着它能对真实世界产生副作用。发邮件、改数据、执行命令这些操作一旦出错后果可能很严重。安全边界必须在工程层面强制不能指望模型自觉。基本的安全措施包括权限控制Agent 只能调用被授权的工具、操作确认危险操作需要人工确认或二次验证、输入过滤防止提示注入导致 Agent 执行非预期操作、输出审查Agent 生成的内容在对外发送前要检查。提示注入是 Agent 特有的安全风险。攻击者可能在 Agent 读取的数据里嵌入指令诱导 Agent 执行非预期操作。防御方法包括把外部数据和系统指令明确分隔、对数据来源做标记、关键操作不依赖模型判断而是走固定流程。3. 七个决策点搭建 Agent 时真正要做的选择理解了七个要素接下来是实际搭建时的七个关键决策。每一个决策都会影响系统的稳定性、成本和可维护性。3.1 决策一用框架还是自己写循环这是第一个要面对的选择。市面上有 LangChain、LlamaIndex、AutoGPT 这类框架也有各种轻量方案。我的判断标准是看你对循环控制的需求有多精细。框架的好处是开箱即用工具定义、循环、记忆这些都有现成实现上手快。但框架的抽象层往往很厚当你想精细控制循环行为、优化 token 使用、处理特殊错误时会发现处处受限。而且框架版本更新快升级可能带来不兼容。自己写循环的好处是完全可控每一行代码你都知道在做什么优化和排错都直接。代价是要自己处理所有细节前期投入大。我的实际选择是原型阶段用框架快速验证生产阶段自己写核心循环。核心循环其实不复杂几百行代码就能覆盖主要逻辑但可控性带来的收益很大。工具定义、记忆存储这些可以用现成库但循环和决策逻辑自己掌握。3.2 决策二工具调用的格式怎么定工具调用的格式决定了模型输出和系统解析之间的契约。常见的有两种基于模型原生工具调用能力比如某些模型内置的 function calling或者自定义 JSON 格式让模型输出。原生工具调用的好处是模型经过专门训练输出稳定解析简单。缺点是受模型限制换模型可能要改。自定义格式的好处是灵活任何模型都能用缺点是需要靠提示词约束稳定性差一些。我的经验是如果主模型支持原生工具调用优先用原生的稳定性明显更好。如果需要在多个模型间切换或者模型不支持就用自定义 JSON但要在提示词里给足示例并且解析时做容错。自定义格式时有个技巧让模型输出的 JSON 用特定标记包裹比如tool_call.../tool_call解析时先提取标记内容再解析 JSON。这样即使模型在 JSON 前后加了说明文字也能正确提取。3.3 决策三上下文怎么管理上下文管理直接决定 Agent 能跑多复杂的任务、成本有多高。核心矛盾是信息越多模型判断越准但 token 消耗越大、越容易超出窗口。我的策略是分层管理。系统提示和工具定义是固定的每次都带当前任务的目标和计划放在显眼位置工具调用结果做截断只保留关键字段历史轮次定期压缩。具体操作上工具返回结果我会做预处理如果是列表只保留前 N 条加总数如果是长文本提取关键段落如果是结构化数据只保留相关字段。这个预处理可以在工具实现里做也可以在回填上下文前做。我倾向于在工具实现里做因为工具最清楚自己返回的数据里哪些是关键的。还有一个技巧是用引用代替内容。比如工具返回了一个大文件的内容上下文里只放文件路径和摘要需要详细内容时再让模型调用读取工具。这样上下文占用小需要时又能拿到完整信息。3.4 决策四循环什么时候停循环终止条件的设计直接关系到 Agent 会不会卡死或者过早放弃。我设置的终止条件按优先级排列模型输出最终答案正常终止、达到最大循环次数保护性终止、连续两次调用相同工具且参数相同死循环保护、工具连续报错超过阈值异常终止、token 预算耗尽成本保护。这里有个细节模型输出最终答案时怎么判断它是真的完成了还是只是不想继续了我的做法是在系统提示里明确要求完成任务时要输出特定标记比如任务完成开头。同时检查任务目标是否达成如果模型说完成但明显没做完可以提示它继续。最大循环次数的设定要结合任务类型。信息查询类任务通常 3 到 5 轮就够复杂分析类可能 10 到 15 轮。我一般先设一个保守值观察实际运行的循环次数分布再调整。3.5 决策五错误怎么处理和恢复Agent 运行中出错是常态工具超时、返回格式不对、模型输出解析失败、外部服务不可用。错误处理做得好不好决定了 Agent 是偶尔能用还是稳定可用。我的错误处理分三层。第一层是工具内部超时重试、异常捕获、返回结构化错误信息。第二层是循环控制工具报错时把错误信息回填给模型让它决定是重试、换工具还是放弃。第三层是系统级连续错误超过阈值时终止任务记录日志通知人工。关键点是错误信息要回填给模型。很多实现里工具报错就直接终止了其实模型看到错误信息后往往能自己调整。比如查询工具返回用户ID不存在模型可能会去调用另一个工具先查正确的用户ID。给模型自我修正的机会能显著提升任务成功率。但也要防止模型在错误上死循环。如果同一个工具连续报错三次就不要再让它重试了直接终止并报告。3.6 决策六怎么评估 Agent 好不好用Agent 的评估比普通模型评估复杂因为它涉及多步执行和外部交互。不能只看最终答案对不对还要看过程是否合理、成本是否可接受。我用的评估维度包括任务完成率成功完成的任务占比、平均循环次数反映效率、平均 token 消耗反映成本、工具调用准确率调用是否正确、参数是否合理、错误恢复率出错后能恢复的比例。评估方法上我会准备一批测试任务覆盖典型场景和边界情况每次改动后跑一遍看指标变化。测试任务要包含简单单步任务、多步任务、需要错误恢复的任务、容易触发循环的任务。这样才能全面反映 Agent 的能力。有个容易忽视的点是评估要自动化。人工评估成本高、不一致尽量把评估标准量化用脚本自动跑。对于需要判断质量的场景可以用另一个模型做评估LLM as judge但要设计好评判标准。3.7 决策七怎么部署和监控Agent 部署和普通服务部署有区别主要是它的执行时间长、资源消耗波动大、失败模式多。部署上我建议异步执行。Agent 任务可能跑几十秒甚至几分钟同步接口容易超时。用任务队列提交任务后返回任务ID客户端轮询或通过回调获取结果。这样也方便做限流和资源控制。监控要覆盖几个关键指标任务成功率、平均执行时长、token 消耗分布、工具调用失败率、循环次数分布。这些指标能帮你发现系统性问题。比如循环次数突然上升可能是某个工具返回格式变了token 消耗上升可能是上下文管理出了问题。日志要记录完整的执行轨迹每一轮的模型输入输出、工具调用和结果、终止原因。出问题时这些日志是排查的唯一依据。我一般会把轨迹存成结构化格式方便查询和分析。4. 工具调用与循环机制的工程细节前面讲了要素和决策这一节深入两个最核心的工程细节工具调用和循环机制。这两块做不好Agent 基本没法用。4.1 工具定义的 schema 设计工具定义的质量直接决定模型调用的准确性。一个好的工具定义包含名称简洁明确、描述做什么、何时用、参数名称、类型、是否必填、描述、返回值说明。参数描述要特别用心。模型经常在参数上出错往往是因为描述不清。比如一个日期参数如果只写日期模型可能传今天昨天这种自然语言。如果写日期格式 YYYY-MM-DD例如 2024-01-15模型就会传正确格式。枚举类型的参数要把所有可能值列出来。比如操作类型参数要明确列出create/read/update/delete而不是让模型猜。必填和选填要分清。必填参数缺失时校验会失败选填参数缺失时要用默认值。我见过把选填参数标成必填导致模型每次都硬编一个值的反而引入错误。4.2 参数校验与自动修正模型输出的参数不能直接信必须校验。校验内容包括必填字段是否存在、类型是否正确、值是否在允许范围、格式是否符合要求。校验失败时的处理策略能自动修正的自动修正不能修正的返回错误让模型重试。自动修正的典型场景字符串数字转数字、单值转数组、日期格式标准化、枚举值大小写修正。这些修正不改变语义可以直接做。不能自动修正的要把具体的错误信息返回给模型。错误信息要包含哪个参数错了、期望什么、实际是什么。比如参数 start_date 格式错误期望 YYYY-MM-DD实际收到 2024年1月15日。模型看到这个信息通常能自己改对。要注意的是校验和修正逻辑要放在工具执行之前避免带着错误参数执行产生副作用。4.3 循环中的状态跟踪Agent 在多轮循环中需要知道自己做到哪了。没有状态跟踪模型容易重复劳动或者遗漏步骤。状态跟踪的实现方式是在上下文里维护一个任务状态区记录任务目标、已完成的步骤、当前步骤、待完成步骤、已收集的关键信息。每轮循环后更新这个状态区。这个状态区可以由模型自己维护每轮输出时更新也可以由系统维护根据工具调用记录自动更新。我倾向于系统维护关键状态比如已调用了哪些工具、得到了什么结果模型维护计划状态比如当前在哪个步骤。两者结合既准确又灵活。状态区要精简只放关键信息。把所有历史都塞进去就失去了意义反而增加 token 负担。4.4 防止循环失控的几种手段循环失控是 Agent 最常见的故障。表现包括反复调用同一工具、在两个工具间来回切换、不断生成相似的计划但不执行。防御手段有几个层次。提示词层面明确告诉模型不要重复调用相同工具、如果连续几次没有进展要重新评估策略。循环控制层面检测重复调用连续两次相同工具相同参数就干预。状态层面在状态区显示你已经调用过 X 工具了结果是 Y提醒模型不要重复。干预的方式可以是终止循环也可以是插入一条系统消息提醒模型。我一般先用提醒如果提醒后还是重复再终止。提醒消息比如你刚刚已经调用过查询工具并得到了结果请基于这个结果继续不要重复查询。还有一种失控是假进展模型每轮都输出一些内容看起来在推进实际上没有实质动作。检测方法是看是否有实际的工具调用和新的信息获取。如果连续几轮只有文本输出没有工具调用且任务未完成就要干预。5. 记忆管理与上下文压缩的实操记忆和上下文是 Agent 工程里最考验设计能力的部分。这一节讲具体怎么做。5.1 短期记忆的滚动窗口策略短期记忆就是当前任务的对话历史。最简单的做法是全量保留但很快会超出上下文窗口。滚动窗口是保留最近 N 轮但会丢失早期信息。我的做法是分层保留最近几轮保留完整内容更早的轮次只保留摘要。具体是最近 3 轮完整保留第 4 到第 10 轮保留每轮的关键信息调用了什么工具、得到了什么关键结果10 轮以前只保留一个整体摘要。摘要的生成可以在轮次滚出完整保留区时触发用模型生成一段简短总结。这样既控制了 token又保留了必要信息。要注意的是任务目标和关键约束要始终保留在上下文里不能被滚动掉。这些通常放在系统提示或固定的状态区不参与滚动。5.2 长期记忆的检索与注入长期记忆用于跨任务的信息复用。实现上通常是任务开始时根据用户输入检索相关历史把检索结果注入上下文。检索的关键是时机和数量。不是每个任务都需要检索简单任务直接做就行。判断标准是任务是否依赖历史信息。比如帮我再查一下上次那个订单明显需要检索今天天气怎么样就不需要。检索数量控制在 3 到 5 条。太多会干扰模型而且增加 token。检索结果要标注来源和时间让模型知道这是历史信息。长期记忆的存储我建议用向量数据库加结构化字段。向量用于语义检索结构化字段用于过滤比如按用户ID、时间范围。纯向量检索容易召回不相关的内容加上结构化过滤能显著提升准确率。5.3 上下文压缩的具体做法上下文压缩是控制 token 的核心手段。压缩的对象主要是工具返回结果和历史轮次。工具返回结果的压缩在工具实现里做最合适。原则是只返回模型决策需要的信息。比如查询返回 100 条记录模型通常只需要知道总数和前几条样例不需要全部。返回时给总数加前 5 条需要更多时模型可以再调分页参数。历史轮次的压缩用摘要。把多轮交互压缩成一段描述保留关键决策和结果。摘要要包含做了什么、得到了什么、有什么结论。不要包含过程细节。压缩的触发时机当上下文 token 接近阈值时触发或者定期触发。我一般设一个阈值比如上下文窗口的 70%超过就压缩最老的部分。5.4 记忆污染的防范记忆污染是指错误或恶意的信息进入记忆影响后续任务。这在多用户或多任务共享记忆时尤其要注意。防范措施包括记忆写入前做校验格式、来源、内容合理性、记忆读取时做相关性过滤、敏感信息不写入长期记忆、不同用户/任务的记忆隔离。还有一个细节是记忆的时效性。有些信息会过期比如用户当前的会员等级。这类信息要么不存长期记忆要么存储时带时间戳读取时检查是否过期。6. 从 Demo 到生产稳定性与成本控制Demo 能跑通和生产能稳定运行之间隔着稳定性、成本、可观测性三座山。这一节讲怎么翻过去。6.1 稳定性问题的常见来源Agent 生产环境的稳定性问题我总结下来主要来自几个方面。模型输出的不确定性同样的输入模型可能给出不同的工具调用。这在 Demo 里不明显在生产里会导致行为不一致。缓解方法是加强提示词约束、降低温度参数、对关键决策做校验。外部依赖的不可靠工具依赖的 API 可能超时、限流、返回异常。必须做超时控制、重试、降级。重试要带退避避免雪崩。上下文膨胀长任务中上下文不断增长最终超出窗口导致失败。必须做压缩和截断。循环失控前面讲过必须有终止保护。并发问题多个任务同时运行时共享资源比如记忆存储可能冲突。需要做好隔离和锁。6.2 成本控制的几个抓手Agent 的成本主要来自模型调用。一次任务多次调用成本是普通对话的数倍甚至数十倍。控制成本要从几个方面入手。减少不必要的调用能用规则判断的不用模型。比如工具返回结果是否为空用代码判断就行不用问模型。用轻量模型处理简单环节不是所有环节都需要最强模型。参数校验、结果判断这些可以用小模型。控制上下文长度上下文越长每次调用越贵。压缩上下文直接降低成本。设置 token 预算每个任务设一个 token 上限超过就终止。防止个别任务消耗过多。缓存相同或相似的查询结果可以缓存避免重复调用。我实际项目里通过这些手段能把成本降低一半以上。关键是每个环节都要问一句这个模型调用真的必要吗。6.3 可观测性建设Agent 出问题时没有可观测性基本没法排查。必须记录完整的执行轨迹。我记录的字段包括任务ID、用户输入、每一轮的模型输入输出、工具调用及参数、工具返回、每轮的 token 消耗、终止原因、总耗时。这些存成结构化日志方便查询和统计。基于这些日志可以做很多分析哪些工具调用最频繁、哪些任务最容易失败、token 消耗的分布、循环次数的分布。这些分析能指导优化方向。告警要设置关键指标任务失败率、平均耗时、token 消耗异常。超过阈值就告警及时发现系统性问题。6.4 灰度与回滚Agent 的改动提示词、工具、模型都可能影响行为不能直接全量上线。要灰度发布先小流量验证观察指标正常再扩大。回滚机制要准备好。提示词、工具定义这些配置化出问题能快速切回旧版本。模型切换也要能快速回退。我一般会保留最近几个版本的配置出问题时对比新旧版本的执行轨迹快速定位是哪个改动导致的。7. 一些踩坑后的经验总结最后分享几个我在实际项目中踩过坑才明白的点都是文档里不会写的。工具描述比工具实现更重要。我花在写工具描述上的时间比写工具实现还多。描述写好了模型调用准确率能提升一大截。不要相信模型的我完成了。模型经常在没完成时说自己完成了。要有独立的完成判断比如检查关键结果是否存在。错误信息要具体。笼统的错误信息模型没法利用具体的错误信息模型能自己修正。这个投入产出比很高。循环次数要监控。循环次数突然上升往往是问题的早期信号比任务失败更早暴露问题。上下文里放什么比放多少重要。精简但关键的信息比全量但冗余的信息效果好得多。测试用例要覆盖失败场景。只测正常流程的 Agent上线后会被各种异常打垮。要专门构造工具报错、参数错误、循环失控的场景来测。提示词要版本管理。提示词的改动对行为影响很大必须像代码一样管理能追溯、能回滚。别追求一次做完美。Agent 系统是迭代出来的先跑通核心流程再逐步优化稳定性、成本、体验。一开始就追求完美往往什么都做不出来。这套东西我前后迭代了好几轮从最初几十行的 Demo 到现在能稳定处理复杂任务的系统每一步都是被实际问题推着走的。希望这些经验能让你少走一些弯路。Agent 工程化这件事概念不难难的是把每个细节都处理到位而细节恰恰决定了它能不能真正用起来。