1. Agent 到底是什么先搞清楚七要素干 Agent 工程这两年我最大的感受是大家一上来就聊 LangGraph、AutoGen、多智能体协作结果连最基本的 Agent 定义都是模糊的。其实剥掉所有框架和概念外衣一个能被工程化落地的 AI Agent本质上就是七个要素的组合。搞清楚这七个要素你再看任何框架、任何架构图都能一眼看穿它的设计意图。1.1 目标没有目标的 Agent 不叫 Agent很多初学者觉得目标就是用户输入的 prompt这是最大的误解。在 Agent 工程里目标是用户的意图经过解析和约束之后所形成的一个明确的、可验收的预期结果。真正工程化的做法是系统先把用户输入做意图识别和参数抽取再拼接系统提示词中的目标约束条件最后形成结构化的任务指令。比如用户说帮我查一下上季度华东区的销售额并做成周报Agent 的 Goal 应当是{region: 华东区, time_range: 上季度, metric: 销售额, output_format: 周报}这组结构化字段而不是那一句自然语言。实操建议是在工程实现里把目标单独建模。不要试图从 context window 里临时推断目标要用一个显式的 Goal 节点维护目标状态让 Agent 在每一步决策时都能回溯到这个最高优先级信息。这个目标状态会在后续的规划、反思环节反复被引用甚至要支持目标的动态调整机制——当用户中途追加条件Agent 能判断是重规划还是原地继续。1.2 感知Agent 的输入边界感知决定了 Agent 能看到什么。工程实现中感知层要做的工作比绝大多数人以为的要多得多它不只是把用户输入交给 LLM而是要做输入的多路汇聚、环境信息采集、多模态数据解析以及输入预处理。一个 Agent 要落地感知层的设计会直接决定它的适用范围。比如一个客服 Agent感知层需要接收用户文本、历史工单、页面操作上下文甚至用户浏览器端埋点数据一个金融分析 Agent感知层要读取行情 API、财报 PDF、新闻流。感知层的预处理还包括去噪、截断、格式统一、隐私脱敏、语义压缩。我在项目里调试了很久才意识到感知层的输出质量直接决定了后续推理的准确率。你喂给 Agent 的上下文如果是杂乱无章的原文再强的规划策略也救不回来。1.3 记忆短期、长期和工作记忆记忆是 Agent 区别于普通对话模型的核心能力也是工程上最值得投入的部分。我把记忆分成三层来理解短期记忆即对话上下文窗口受模型 token 限制用完即走工作记忆当前任务执行过程中产生的中间状态、临时变量、工具返回结果长期记忆跨会话沉淀下来的用户偏好、领域知识、历史决策记录通常落到向量数据库或知识图谱里。工程落地时短期记忆交给 LLM 的 context工作记忆需要由状态容器管理比如 LangGraph 的 State 对象长期记忆则要独立设计存取接口。很多团队做 Agent 做到后面发现效果不稳定仔细排查下来都是记忆机制混成一团——该放工作记忆的放进了长期记忆该长期记忆的却在每次对话里重复塞进上下文导致 token 浪费和上下文污染。1.4 规划把任务拆成可执行步骤规划是 Agent 的大脑皮层。它负责把目标拆解成一个有序的、可执行的步骤序列并决定每一步调用什么工具、依赖什么数据、产生什么中间产物。这里的核心技术就是任务分解现在最常用的几种范式是 ReAct、Plan-and-Execute、思维树ToT和自问自答Self-Ask。我在工程化过程中强烈推荐以 Plan-and-Execute 为主干、ReAct 为兜底的混合策略。原因很简单Plan-and-Execute 先把任务一次性拆成 DAG有向无环图执行路径清晰可控方便做并发优化但现实场景中任务往往会有未知分支这时再退回到 ReAct 模式的思考-行动-观察循环动态补充计划。这个结合方案在追求可控性和流式输出的生产环境里表现明显优于单一模式。1.5 工具Agent 的四肢没有工具调用的 LLM 只能停留在纸上谈兵。工具层把外部能力封装成 Agent 可调用的接口包括搜索引擎、数据库查询、代码执行器、文件读写、HTTP API、通知推送等。工程上工具的核心不是写代码而是 Function Calling 的协议设计——你要把函数的语义描述清楚让 LLM 知道什么情况下该用、参数该怎么填、返回结果代表什么。我在设计工具时坚持一个原则每个工具必须带完整的参数 schema、明确的触发条件说明、以及错误返回的约定。工具返回的结果还要做结构化封装不能用自由文本返回否则 Agent 解析依赖信息会非常痛苦。工具调用失败也要返回标准错误码Agent 才能基于错误码做重试或换工具。实际生产环境里工具这块的坑远比你想象的多一个参数描述不准确就可能让模型无休止地传错参追查起来的成本远高于调用 token 成本。1.6 行动执行和反馈闭环行动是 Agent 真正触达外部世界的那一步——调用工具、发起网络请求、执行代码。工程上行动层要处理好三件事动作选择、动作执行、反馈回收。动作选择是规划步骤落地为具体操作动作执行要有一套统一的 executor 来跑避免每类工具各写各的调用逻辑反馈回收就是把工具结果、异常信息、执行耗时转回给 Agent作为下一步决策依据。一个关键细节是行动层需要做超时控制和重试策略。LLM 规划出一个步骤可能实际执行就卡住了第三方 API 超时、数据库锁等待、外部服务 5xx。我在生产环境里统一给工具执行器加了超时熔断和指数退避重试默认超时 15 秒、最多重试 2 次跑了一个多月效果非常稳。这块如果你不做Agent 在处理真实任务时会被各种外部系统的偶发故障拖垮。1.7 反思Agent 的自我纠错反思是七要素里最被低估、但恰恰最能拉开成品体验差距的环节。反思不是让 LLM 自言自语我再想想而是基于执行结果的结构化反馈让 Agent 判断当前路径是否正确。实现反思最务实的方式是把计划、中间结果、最终结果、预期结果四者对拍然后给模型一个决策点让它选择复盘还是止损。工程上可以落地两种反思机制一种是任务完成后的总结式反思沉淀经验到长期记忆里下次类似任务更高效另一种是执行过程中的即时反思——当某一步工具返回结果与预期不符Agent 判定当前计划可能走偏触发重新规划或启动修复流程。后者的价值更大但实现难度也更高因为它要求你为 Agent 设计一个判断信号的机制让模型在关键节点主动停下来检查而非闷头走到底。2. 工程实现的七个决策点要素是理论框架但从理论到可以上线的 Agent 系统中间隔着大量工程决策。我这里总结了七个决策点是我自己做项目时反复权衡过、也踩过坑的地方基本每个都能决定项目的成败方向。2.1 决策点一Agent 类型选型这是第一个要拍的板你要做的是单 Agent 还是多 Agent如果你拿不准我的建议是优先选择单 Agent 工具增强的架构。多 Agent 听起来很高级但实际工程复杂度是成倍增长的——你要处理 Agent 间的通信协议、职责边界、冲突仲裁还要为每个 Agent 配记忆和反思这对初创团队或者中小型项目来说是非常重的负担。单 Agent 工具架构的好处是整个执行链路由一套状态机控制错误定位清晰调试成本低token 消耗也可控。只有当你的任务天然具备多角色协作的特性比如一个编排型系统同时涉及信息收集、数据分析、内容生成三个强隔离的子任务再考虑引入多 Agent而且要选择确定性通信框架比如 LangGraph 的 supervisor 模式或 MetaGPT 的协作协议。2.2 决策点二框架选型框架决定了你的开发效率和后期维护成本这个决策我建议你从可控性这个维度来拍板。目前主流的 Agent 框架有几个LangChain 生态的 LangGraph、微软的 AutoGen、CrewAI、LlamaIndex以及 Spring AI AgentJava 技术栈的同学用得比较多。我的经验是如果你要做一个严肃的生产级系统LangGraph 是目前最值得投入的选项因为它把状态机、节点、条件边这层抽象暴露得非常清晰图的执行流程你可以完全掌控。AutoGen 在对话式多 Agent 场景有优势适合研究原型CrewAI 上手快但可控性偏弱复杂流程容易失控Spring AI Agent 对 Java 团队友好但生态成熟度比 Python 系还有差距。这里多说一句不要被框架的 Star 数带着走你要评估的是框架的状态管理机制是否透明、是否支持运行时动态分支、工具调用是否有完善的协议层。选错框架后面的重构成本够你写两版业务代码。2.3 决策点三状态与上下文管理Agent 跑了十步、二十步之后所有中间状态如何组织这是生产环境和新手代码最大的分水岭。我的建议是所有状态都必须收敛到一个显式的 State 对象里并明确每个字段的生命周期。临时变量用完即清重要中间结果要按结构存储不要在每一步调用里把全部历史塞给模型——我见过太多 Agent 跑着跑着 token 用量爆炸查下来就是每轮迭代把 messages 全量携带。实现上有一个比较实用的分层策略把状态分为任务态、环境态、用户态三层。任务态存当前步骤的执行产物、工具返回环境态存全局配置、外部系统凭据用户态存用户偏好和跨任务信息。每次模型调用时只组装当前步骤真正需要的状态片段而不是一股脑全部注入。这样一个看似简单的分层能让你的上下文干净很多推理准确率也会上升不少。2.4 决策点四并发与流量控制热搜里总有人在问AI Agent 怎么扛并发这个问题非常现实。Agent 与普通接口最大的不同在于一次 Agent 任务可能持续几秒甚至几分钟期间要多次调用 LLM、多个工具链式依赖这对后端并发模型是很大的挑战。我建议的核心策略是把 Agent 任务的执行线程和请求线程彻底分离采用任务队列 异步 worker 的架构。用户请求进来先入队立刻返回 task_id由 Worker 池异步消费并推进 Agent 状态机。并发上限的控制要有三个维度的闸门LLM 服务商的 RPM/TPM 限流、工具依赖系统的承受能力、以及 Agent 任务本身的资源密度。此外要做动态限流不能简单写死 QPS——因为不同任务调用 LLM 的次数差异很大要看 token 消耗速率来限流。生产环境里我用 Redis 计数器做分布式限流配合基于令牌桶的速率控制器实测能稳定扛住每天百万级任务调度。2.5 决策点五LLM 调用与成本优化模型调用是所有 Agent 工程中成本最大、也最值得优化的环节。我总结了几条立竿见影的成本控制手段规划用推理型强模型、执行用轻量快模型形成大小模型协作的分层调度对工具返回结果做摘要和截断避免把大段 JSON 或日志原文塞进上下文优先使用 prompt 缓存把系统提示词、工具定义、历史摘要等不变部分做缓存化处理设置最大迭代步数上限防止 Agent 在错误路径上死循环烧钱我默认设 8 步。成本优化的前提是要有可量化的指标。我会在 Agent 的每次模型调用的空间里记录 prompt_tokens、completion_tokens、模型名、步骤名按天聚合出全链路的 token 消耗分布。没有这个数据你做任何优化都是拍脑袋。2.6 决策点六可观测性与调试Agent 系统调试有多痛苦做过的人都懂一个几十步的任务中间任何一步理解偏差最终结果就面目全非。所以可观测性不是可选项是必需品。我在项目里坚持对 Agent 生命周期做全程追踪最少要记录四个维度轨迹trajectory、成本、时间、状态演化。轨迹日志是核心每一步的输入输出、模型推理内容、工具调用入参、返回结果、Agent 的思考过程都要留痕。我建议把轨迹日志落到结构化存储比如 ClickHouse 或 ES每条 trace 带统一的 trace_id方便按任务维度聚合。一旦线上出问题用 trace_id 一把梭查到底效率会比你盲调 prompt 高十倍。调试阶段还可以做回放把轨迹虚拟化重跑做回归对比——这在迭代 Agent 的 prompt 或工具定义时非常有用。2.7 决策点七部署与服务化最后一个决策点是 Agent 系统怎么上线跑起来。Agent 服务不能做成同步阻塞的 HTTP 接口——因为单次 Agent 任务可能跑几十秒同步接口很容易拖垮连接池还会让用户面对超时。必须设计成异步任务模式提交任务、后台执行、结果通过回调或轮询获取。前端交互则优先使用 SSEServer-Sent Events或 WebSocket 做流式效果让 Agent 的每一步进展实时推给用户。部署形态上核心 Agent 执行引擎用无状态服务 Redis 存储瞬时状态Worker 数量可以水平伸缩。记忆数据库和 Trajectory 存储则根据规模选型小项目用 PostgreSQL pgvector大规模再上独立的向量库。容器化之后要注意给 Agent 引擎设置内存上限因为 Agent 在中间步骤会产生不少大对象比如工具返回的列表、构建中的文档内存泄漏在长跑任务中特别容易出现我会在每一轮状态转换后做一次显式的资源清理。3. 实操从零搭一个带记忆与反思的最小 Agent理论说再多不动手等于零。这一节我会带你用 LangGraph 搭一个包含七要素和关键决策点的最小 Agent。这个 Agent 要做的事情很简单根据用户输入的自然语言任务调用两个工具一个做搜索、一个做计算最终返回一份结构化结果。别看简单它把我们前面讲的七要素、状态管理、反思机制、成本控制全部串起来了。3.1 定义状态容器开始写代码之前先定义 Agent 的状态数据结构。这是整个工程的基石直接对应前面说的状态管理决策点。from typing import TypedDict, Annotated, List, Optional import operator class ToolResult: 工具返回的标准结构 def __init__(self, success: bool, data: Optional[object], error: Optional[str] None): self.success success self.data data self.error error class AgentState(TypedDict): input: str # 原始用户输入 goal: dict # 结构化目标 plan: List[str] # 任务拆解后的步骤列表 current_step: int # 当前执行到的步骤 messages: Annotated[List[dict], operator.add] # LLM 调用历史 tool_outputs: dict # 工具返回结果的缓存 reflection: str # 反思节点输出 final_result: Optional[str] # 最终输出 step_count: int # 已执行步数成本控制用 max_steps: int # 最大步数上限这里我特别想强调 messages 字段的类型标注 Annotated[List[dict], operator.add]——它告诉 LangGraph 这个字段在节点间传递时使用累加操作而非覆盖操作这确保每轮 LLM 调用产生的消息会被保留。而 tool_outputs 用普通 dict是为了让工具结果写入时按 key 覆盖避免状态无限膨胀。3.2 目标解析与规划节点构建图之前先定义两个关键节点一个是目标解析器把用户输入变成结构化目标一个是规划器把目标拆成步骤列表。def parse_goal(state: AgentState) - AgentState: 将用户输入解析为结构化目标。实际项目中可以调用一个小模型做意图识别。 raw state[input] # 这里简化处理真实场景建议用 LLM 抽取 # 例用户输入帮我搜索RAG最新进展并统计引用次数 goal { action: search_and_summarize, query: raw, metrics: [references], } return {**state, goal: goal} def planner_node(state: AgentState) - AgentState: 根据目标生成执行计划。生产环境用强模型这里展示核心逻辑。 goal state[goal] plan [ 调用搜索工具获取相关内容, 提取每条结果的引用次数并汇总, 基于搜索结果生成结构化总结, ] return {**state, plan: plan, current_step: 0, step_count: state[step_count] 1}这里你可以看到工程落地的细节第一步 parse_goal 用轻量模型甚至正则规则完成不用花钱调大模型第二步规划器用的是推理能力更强的模型。这正好对应前面说的大小模型协作的成本优化策略。3.3 工具节点搜索与计算接下来是工具节点展示标准化的工具封装方式。import requests import re def search_tool(query: str) - ToolResult: 模拟搜索 API。生产环境替换为真实的搜索引擎接口。 try: # 模拟网络请求 resp requests.post(https://your-search-service/api/v1/search, json{q: query}, timeout10) if resp.status_code ! 200: return ToolResult(False, None, fHTTP {resp.status_code}) return ToolResult(True, resp.json()) except Exception as e: return ToolResult(False, None, str(e)) def calc_tool(expression: str) - ToolResult: 计算工具,只允许白名单操作。 allowed set(0123456789-*/(). ) if not all(c in allowed for c in expression): return ToolResult(False, None, 非法表达式) try: result eval(expression) # 注意生产环境使用更安全的方式 return ToolResult(True, result) except Exception as e: return ToolResult(False, None, f计算失败: {e}) def tool_executor(state: AgentState) - AgentState: 根据当前计划步骤执行对应工具。 plan state[plan] step state[current_step] step_desc plan[step] if 搜索 in step_desc: result search_tool(state[goal][query]) state[tool_outputs][search_result] result return {**state, tool_outputs: state[tool_outputs], current_step: step 1, step_count: state[step_count] 1} if 引用次数 in step_desc: search_result state[tool_outputs].get(search_result) if not search_result or not search_result.success: return {**state, reflection: 搜索步骤未完成无法统计次数} # 简化写一个正则从搜索结果里抽数字 counts [int(m) for m in re.findall(r\d, str(search_result.data))] state[tool_outputs][total_refs] sum(counts) return {**state, tool_outputs: state[tool_outputs], current_step: step 1, step_count: state[step_count] 1} return state TOOLS {search: search_tool, calc: calc_tool}工具标准化体现在哪里你看 search_tool 和 calc_tool 都返回 ToolResult 这个统一结构这样不论工具内部多复杂Agent 在做决策时拿到的都是 success / data / error 三个标准字段。后续如果加新工具只要实现同样的协议就能直接被 Agent 调用不需要改核心逻辑。3.4 反思节点执行态护栏反思节点是这个 Agent 的保险丝。我在工具执行节点后插入一个条件判断如果执行轨迹出现明显异常就强制触发重新规划。def reflect_node(state: AgentState) - AgentState: 检查执行轨迹判断当前计划是否仍然有效。 step_count state[step_count] tool_outputs state[tool_outputs] # 规则一超过最大步数立即停止 if step_count state[max_steps]: return {**state, reflection: max_steps_reached} # 规则二工具失败且无可用兜底结果 for key, output in tool_outputs.items(): if isinstance(output, ToolResult) and not output.success: # 允许一次重试但重试后仍失败则中止 if state.get(f{key}_retried): return {**state, reflection: ftool_failed_no_retry: {key} - {output.error}} else: return {**state, f{key}_retried: True, reflection: fretrying_{key}} # 规则三计划已经执行完进入生成总结阶段 if state[current_step] len(state[plan]): return {**state, reflection: plan_completed} return {**state, reflection: continue}反思节点根本不用调 LLM用几条规则就能把绝大多数的死循环和错误路径拦截掉成本为零。这也是一种工程智慧能确定性判断的绝不花钱让模型猜。3.5 组装状态图并执行最后一步用 LangGraph 把上面的节点串起来定义条件边构建可执行的状态图。from langgraph.graph import StateGraph, END # 初始化状态图 graph StateGraph(AgentState) # 注册节点 graph.add_node(parse_goal, parse_goal) graph.add_node(planner, planner_node) graph.add_node(execute, tool_executor) graph.add_node(reflect, reflect_node) # 定义入口 graph.set_entry_point(parse_goal) # 普通流转 graph.add_edge(parse_goal, planner) graph.add_edge(planner, execute) graph.add_edge(execute, reflect) # 条件路由反思结果决定下一步走向 graph.add_conditional_edges( reflect, lambda state: state[reflection], { continue: execute, # 继续下一步 plan_completed: END, # 计划完成后续可接汇总节点 max_steps_reached: END, # 超步数强制终止 tool_failed_no_retry: END, # 工具失败不可重试 retrying_search: execute, # 重试搜索 } ) app graph.compile() import json # 执行一次 Agent 任务 state app.invoke({ input: 帮我搜索RAG的最新进展并统计引用次数, messages: [], tool_outputs: {}, step_count: 0, max_steps: 8, }) print(最终反思状态:, state[reflection]) print(工具缓存 keys:, list(state[tool_outputs].keys())) print(累计步数:, state[step_count])这段代码跑通之后你就能看到一个 Agent 任务的状态流转全过程解析目标 → 生成计划 → 执行工具 → 反思检查 → 条件路由。你可以在此基础上加一个总结生成节点把 tool_outputs 里的数据交给 LLM 生成最终交付文案这就成了一个完整的助手型 Agent。4. 常见问题与排查技巧实录最后这部分我把做 Agent 工程时高频踩坑的问题整理成了一份速查手册。这些问题几乎每一个我都亲自遇到过下面这些排查思路也是我反复验证过真正有效的希望对你有直接帮助。4.1 Agent 陷入死循环最典型的表现是同一个步骤反复执行工具结果来回覆盖token 在持续消耗任务却没有任何实质进展。排查思路是第一查 max_steps 是否生效很多新手在 LangGraph 里设置了步数上限但条件路由里根本没接 max_steps_reached 这个分支模型就会周而复始地跑第二查用户输入里的歧义是否导致了目标解析器反复给出不同结果每次重新规划就跑出一个新分支形成一个环。我的建议是除了步数上限之外再叠加一个重复动作检测在状态里缓存最近 5 步的步骤 hash发现完全相同的连续动作序列就强制终止。另外反思节点里要强制记录为什么重试避免 Agent 在同一个失败工具上无脑重试两次以上。最后还要盯一个现象如果 LLM 每一步都在改 plan 而不是执行 plan说明规划器本身的条件给得太松了要约束规划器只能输出对现有计划的微调而非全量重写。4.2 工具调用参数乱传现象是模型生成的工具参数很接近但就是不正确比如把 user_id 传成了手机号把时间格式从 yyyy-mm-dd 写成了 yyyy/mm/dd。根本原因通常不是模型笨而是你的函数 schema 描述不够清晰。我排查时首先会看工具定义的 JSON Schema重点检查三个地方参数 description 是否写清了取值范围和格式示例必填参数是否标了 required枚举参数是否有 enum 约束。另外我会在工具执行器里做统一的参数校验层不轻信模型的输出。包括必要时的参数类型强制转换、日期格式自动纠正、超范围值的截断。如果模型反复出错就要在系统提示词的工具使用规范部分加一条负向提示明确说明以往的错误格式是什么、正确示例是什么。效果比我调模型参数好得多。4.3 上下文膨胀导致成本和效果双失控这个问题几乎每个 Agent 项目都会遇到。症状是任务跑的时间越长单次模型调用的输入 token 越大响应越慢而且效果反而变差——因为无关信息多了模型注意力被稀释了。核心原因就是前面说的把整个执行历史都作为消息传给模型没有做状态分层和上下文筛选。解决思路有三步。第一步messages 中只保留与当前步骤强相关的最新 N 轮消息一般 N 取 3 到 5更早的信息压缩成摘要后存到长期记忆按需回溯。第二步工具返回结果必须摘要化搜索结果只保留 top 5 条关键字段数据库查询只给行数和聚合值不要返回原始大对象。第三步规划信息和反思信息可以通过工具调用缓存机制只在特定阶段注入。经过这三步处理一个 50 步的长任务token 消耗能下降 60% 到 80%。4.4 并发上来之后状态互相污染这个问题在把 Agent 服务化的时候必现。就是多个用户任务同时在跑A 用户的中间结果串到了 B 用户的状态里或者 Redis 里存状态的时候 key 冲突被覆盖。排查下来大多是状态管理没有做实例隔离导致的。正确做法是Agent 状态的持久化和读取必须带上唯一的 task_id 维度Redis Key 设计成 agent:{task_id}:field 这种格式状态图的 invoke 操作必须是线程安全且无共享可变变量的模型。我用 LangGraph 的持久化 checkpointing 时每个任务绑定单独的 thread_id保证状态快照互不干扰。另外全局的 ToolResult 对象绝不能定义为模块级变量必须随任务走。这块一旦出问题排查成本极高建议在架构设计阶段就定死任务级隔离的原则。4.5 排查实测心得除了上面这些我再分享一个非常实用的排查习惯在 Agent 运行的每一个节点入口和出口打上结构化日志包含当前任务 ID、节点名、输入内容摘要、输出状态、耗时和 token 消耗。出问题时用任务 ID 把所有节点日志拉出来按时间轴看一遍状态变化基本上问题原因一眼就能定位。我过去帮团队排查一个数据汇总 Agent 的输出错误最终就是靠搜索工具返回的结果根本没被解析这条日志追到了根因——工具返回了列表结构但后续节点错误地把它当字典处理了一个字段类型问题如果没有节点日志这一条线索不知道要翻多久才能找到。另外提醒一句不要过度依赖 Agent 的自解释它常常会为自己失败找一个优雅的理由。你必须依赖系统的可观测性工具来还原真实执行路径而不是问模型你怎么想的。数据永远比模型的自我复盘可靠。5. 写在最后的几个体会从我自己的实践来看Agent 工程实现拼的不是某一个惊艳的算法而是把七要素理解透彻之后在七个决策点上做出扎实的选择。要素让你知道 Agent 需要什么决策点让你知道工程上怎么落地。这两层都打通了再回头看你遇到的各种 Agent 项目大概率一眼就能判断出它靠不靠谱、问题出在哪一环。我特别想强调的其实是做减法这三个字。AI Agent 这个领域概念多、框架多、玩法多非常容易陷入什么都想加的冲动里。我自己做过的项目里收益最大的几个优化反而都是减法砍掉多余的工具、压缩冗长提示词、减少无效的规划分支、限制无节制的重试。Agent 不是魔法它只是让一个执行流程在关键环节引入了语言模型的判断力。判断力用到刀刃上工程就稳了。如果你正在做一个 Agent 项目别急着上多智能体、别急着堆框架特性。先把七要素里最核心的三件——稳定的目标、干净的状态、可靠的工具协议——打磨到极致你会发现大多数业务场景已经能跑得很好了。这算是我前后折腾了大半年之后最想分享的一句实在话。