AI Agent 这个概念火了两年多我身边不少朋友从跃跃欲试到开始动手却发现一个很尴尬的问题网上到处都是 Agent 的原理图、宣传稿、Demo 视频真到自己搭一个能用的系统时却又不知道该从哪下手。模型接上了、提示词写了、工具也调通了跑起来还是不像那么回事——要么答非所问要么一步错步步错要么成本高得吓人。这篇文章我不讲玄学就想用一套能落地的框架把 Agent 讲清楚“七要素 七个决策点”。前者告诉你一个 Agent 到底由哪些零件组成后者告诉你工程实现时每个关键路口该怎么拍板。模型选型、架构模式、记忆策略、工具协议、部署形态这些词听着唬人拆开看其实都是一个个能查表、能对比、能照做的选择题。文章里我也会穿插一些自己实际踩过的坑、算过的账和改过的方案希望能帮你少走点弯路。适合正在做 Agent 落地的工程师、技术决策者也适合想搞懂 Agent 内部到底在发生什么的开发者。1. 七要素把 Agent 从“玄学”拆成零件我见过太多团队在讨论 Agent 时各说各话产品说 Agent 是能自动干活的机器人算法说 Agent 是加了 ReAct 的 LLM后端说 Agent 是一个需要维护状态的服务。其实大家都没说错但都只说了一部分。把 Agent 拆到不能再拆的程度我习惯用七个要素来看这七个东西缺一个跑起来都会出问题。打个比方把一个 Agent 想象成一个新入职的员工大模型是他的脑力和判断力任务规划是他在拆解工作目标的方式记忆系统是他的笔记本和档案柜工具调用是他能操作的办公软件和外部系统执行反馈是他在做完一件事后观察结果并调整动作的能力上下文管理是他工作台上能同时摊开多少资料安全边界则是公司的权限审批制度。七要素合在一起才是完整的“数字员工”而不是一个会聊天的机器人壳子。1.1 大模型底座一切能力的上限大模型是 Agent 的推理核心也是决定 Agent 能力上限的那个“天花板”。为什么把它放在第一位因为后面所有要素的效果都受它制约模型不会用工具你的工具定义写得再完美也是白搭模型的指令遵循能力差你的提示词提示得再用力它也会跑偏模型的上下文窗口小你再会做记忆管理它也记不住长对话的来龙去脉。很多团队在规划 Agent 项目时第一件事就是写提示词或者选框架这其实是本末倒置。先说结论动手之前先用一个小评测集把模型“烤”一遍。什么叫烤就是找 30 到 50 条你这个业务里最典型的任务不用多但必须覆盖“需要推理”“需要调用工具”“需要从错误中恢复”这几类场景然后把同一个提示词分别发给候选模型看谁在任务完成率上明显胜出。有一次我给客户做客服 Agent候选模型一个是通用旗舰一个是主打性价比的轻量模型。跑下来通用旗舰在复杂工单上的成功率高出 27 个百分点但价格也贵了将近 4 倍。最后我们做的方案是双模型路由简单问题走便宜模型复杂问题才上旗舰模型。这个思路的前提是你知道每个模型在真实任务上的表现而不是看宣传页上的 benchmark。选模型没有绝对的最优解只有结合你的任务分布算出来的“够用且最省”的解。1.2 任务规划把目标拆成有依赖关系的步骤Agent 和普通聊天机器人最大的区别在哪里聊天机器人是你说一句我回一句Agent 是要把一个目标拆成一段可执行的动作序列。这块在工程上就是任务规划也是 ReAct、Plan-and-Execute 这些架构模式的核心来源。ReAct 是“Thought → Action → Observation”的循环模型先想我该做什么然后做调用哪个工具再看结果工具返回了什么再进入下一轮思考。它的好处是灵活能根据中间结果随时调整路径适合工具调用密集、每一步结果不确定的场景。Plan-and-Execute 则是先规划后执行第一步先生成一份完整的行动计划第二步把计划里的步骤逐一执行不再频繁回顾。它适合目标清晰、步骤相对固定的长任务比如“读取这 50 个文件提取关键信息生成一份周报”。用装修来类比ReAct 像是边装修边改方案每一步看实际情况现场定Plan-and-Execute 像是先出施工图再照着图施工。很多团队一上来就上复杂的规划器结果模型生成计划的能力不够反而把简单任务搞复杂了。我的经验是大多数场景用 ReAct 循环加一个最大步数限制就够了等你的任务真的长到 ReAct 会在中间迷路时再考虑 Plan-and-Execute。1.3 记忆系统短期工作台与长期知识库的取舍记忆是 Agent 工程里最容易被低估的部分。很多 Demo 跑不起来不是因为模型不行而是因为 Agent 没有记忆——对话一超过上下文窗口就“失忆”或者跨会话完全忘掉用户之前的偏好。工程上记忆可以分两层看。第一层是工作记忆就是当前任务执行过程中需要暂存的信息比如正在处理的订单号、上一轮工具返回的结果。这一层通常放在内存或者 Redis 里用一个带 TTL 的 key 存住任务结束就清理。第二层是长期记忆包括用户的画像、历史偏好、之前总结过的结论。这一层需要持久化常见做法是数据库存结构化数据、向量库存语义向量再用一个检索模块在需要时把相关内容拉回上下文。我的建议是别一上来就上向量库。很多 Agent 项目的“长期记忆”需求用 Redis 存 JSON、用 PostgreSQL 存几张表就完全能覆盖。向量检索适合的是“我也说不清用户会问什么只能靠语义相似度去捞”的场景。如果一个记忆需求能用 key-value 表达清楚就绝不引入向量库少一个组件就少一套运维成本和一个故障点。1.4 工具调用让 Agent 长出“手”和“眼睛”没有工具的 Agent 只是一个“纸上谈兵”的顾问有了工具调用能力它才能真正对外部世界产生作用。工具可以是查天气的 API、操作数据库的接口、发消息的服务也可以是执行一段代码的沙箱。工程上工具调用的核心不是写工具本身而是让模型能“看懂你定义的每一个工具”。这里有个容易被忽略的细节:模型调用工具本质上是在输出一个结构化的 JSON——工具名、参数列表、参数值——真正执行那段代码的是你自己写的调度器。所以你要做的是给每个工具写清楚“什么情况下用”“参数是什么格式”“可能返回什么错误”。举个例子定义一个“发送消息”工具如果描述里只写“发送消息参数content”模型大概率会在该发消息时给出一堆乱七八糟的字段。但如果你把工具描述写成一个标准 API 文档的样子包含参数类型、必填非必填、返回值结构、错误码含义模型就很少会犯错。说白了工具描述就是在教 Agent 怎么使用你提供的“外部接口”写得越像给人类工程师看的 API 文档调用成功率就越高。其中值得单独提一句的是 function calling 机制它让模型以结构化方式表达调用意图这也是目前主流 Agent 框架的默认方式。1.5 执行反馈观察结果并修正路径的闭环工具调用发出去了不代表任务就能顺利进行。Agent 工程里最容易翻车的地方恰恰是“工具返回了意外结果之后该怎么办”。这需要 Agent 具备执行反馈的能力也就是把观察到的结果放回上下文让模型判断下一步怎么走。举个例子Agent 要查天气调用了一个天气 API结果这个 API 返回了 503 错误。一个没有反馈设计的基础 Agent 会直接把这个错误当成“查询结果”丢给用户形成很糟糕的体验。而一个有反馈闭环的 Agent会读取错误码、判断是服务暂不可用然后换个数据源重试或者换个关键词重新查询再从工具结果里提取最终答案。要做到这一点工具的返回值必须结构化成统一格式。我在项目里约定所有工具都返回一个包含 status、data、error 三个字段的结构Agent 在下一步思考时首先检查 status再决定是继续执行还是换条路。系统提示词里也会明确写一句“如果工具返回错误先判断能否修复再决定是否放弃。”这句话看着简单但能显著提升长链路任务的完成率。1.6 上下文管理读懂 token 才能控制成本很多初学者第一次听到 token 这个词会懵token 到底是什么简单说token 是模型处理文本的最小计算单元。中文场景下一个字大概对应 1 到 2 个 token英文则是几个字母一个 token。模型不是按字数计价的而是按 token 数。你的 prompt 越长消耗的 token 越多响应时间越长费用也越高。上下文管理就是决定“哪些内容能放进模型的上下文窗口、哪些不能”的策略。每个模型都有一个上下文窗口上限比如常见的 8k、32k、128k。注意这个上限不是一个可以随意填满的池子它要同时容纳系统提示词、用户输入、工具描述、历史对话和模型要生成的输出。如果你把 100k 的内容全塞进上下文模型在长文本里找关键信息的准确率会明显下降这被称为“lost in the middle”效应。工程上控制上下文的办法无非三种截断、摘要、检索。对话太长就只保留最近几轮加一条历史摘要上下文里放不下的工具说明就压缩成精简版需要长期知识时就先从记忆库里检索出最相关的内容再拼接进去。关于 token 成本公式也很直接一次调用的费用等于输入 token 数乘以输入单价加输出 token 数乘以输出单价。很多团队上线 Agent 后发现费用超预算打开日志一看——90% 的 token 都花在了反复把同样的工具描述塞进上下文上。这就是上下文管理没做好。1.7 安全边界护栏不是奢侈品而是必需品Agent 的能力越强破坏力也越大。一个能读邮件、发消息、操作数据库的 Agent如果没有任何权限控制就像把公章放在没人看管的桌子上。所以我一直把安全边界当作七要素里的独立一项而不是一句“注意安全”的提醒。工程上能做的最小安全集合是这几件事一是权限最小化给 Agent 接工具时只给最低必要权限比如只读不写、只能操作单个租户的数据、只能访问指定目录二是关键操作人工确认支付、删除、群发这类动作必须经过一个人审环节三是沙箱执行凡是要跑代码的 Agent代码执行环境隔离到容器里限制网络访问和资源占用。我自己就吃过亏。有次做一个邮件自动回复 Agent给工具列表里加了“发送邮件”的权限测试的时候 Agent 把一封测试邮件同时发给了列表里的所有人。功能上完全符合预期但这个行为本身如果在生产环境发生就是事故。从那以后凡是“有副作用”的工具默认都要加人工确认步骤。护栏这件事宁可过度设计也不能裸奔上线。2. 从“零件”到“装配”七个决策点的全景图七要素讲的是 Agent “由什么组成”但知道零件清单不等于你会装机器。从零实现一个 Agent过程中的每一步都是一道选择题模型选哪个、用什么架构、框架用不用、记忆存哪里、工具协议怎么定、循环怎么终止、服务怎么部署。这些选择加起来才是 Agent 的工程实现。我把它归纳成七个决策点和七要素一一对应但又不完全相同。要素是静态的“有没有”决策点是动态的“怎么选”。要素解决的是“Agent 是什么”的认知问题决策点解决的是“在具体约束下怎么做”的工程问题。比如“记忆”这个要素强调你必须有记忆系统但到了决策点里你要回答的是“用什么存、存多久、怎么检索”这两个层次差着十万八千里。工程上的决策还有顺序依赖先定模型才知道模型的上下文窗口多大进而决定记忆策略和 token 预算先定架构才知道框架要选多重的先定工具协议才知道 Agent 能接哪些系统。后面几节我会按实际项目的推进顺序一个一个过。2.1 决策点一模型选型先定上限再谈优化第一道选择题永远留给模型。模型定了上下文窗口、价格、推理能力、延迟这些硬约束就全定了后面所有决策都要在约束范围内做。选型时先算一笔账你的任务有多复杂如果主要是“从文档里抽字段、调接口、做简单问答”一批开放权重的中小模型就够成本低还能私有化部署。但如果任务里包含复杂推理、多步规划、长文本综合归纳就需要旗舰模型来扛。成本账也得算清楚。闭源 API 的好处是零运维、按量付费、上线快坏处是单价高、有数据外发风险、依赖第三方稳定性。自部署开源模型的好处是单价被摊薄、数据可控坏处是前期要买卡、要调推理服务、要做并发管理。我见过不少团队从闭源 API 切到自部署省下了一大笔钱但前提是他们的模型选型和负载画像足够清晰。一句话总结按任务难度分层选模型别让所有请求都涌向最贵的那一个。2.2 决策点二架构模式ReAct 循环还是 Plan-and-Execute模型定了接下来是决定 Agent 的行为骨架也就是架构模式。这个决策决定了你的 Agent 在遇到任务时是一步一步想、还是一次性列计划再执行。我做一个对比表方便你直接查架构模式核心思想适合场景主要缺点工程复杂度ReAct 循环思考→行动→观察循环往复工具密集、结果多变的动态任务长任务容易迷失token 消耗高低Plan-and-Execute先规划全部步骤再按序执行流程固定、步骤明确的长任务计划生成质量影响整个任务中Multi-Agent 协作多个角色分工互相传递结果需要角色隔离、专业分工的任务状态同步难调试复杂度暴增高从经验来看85% 的 Agent 项目用 ReAct 循环模型就够了。它足够简单、足够直观、调试也容易把每一步的 thought 和 action 打出来一眼就能看出问题在哪。Plan-and-Execute 适合那种你知道完整步骤列表的任务比如“每天九点读一遍新邮件归纳出待办写入任务管理系统”。Multi-Agent 是这三个里最容易被过度使用的两个 Agent 之间互相传数据一旦出错排错的成本比写一个单体 Agent 高得多。除非你能清晰划分出各角色的职责边界否则不建议一上来就上多 Agent。2.3 决策点三编排框架自研还是用现成的框架选择是个特别容易引战的话题。LangChain 出了名地抽象层厚功能全但黑盒也多LlamaIndex 偏重“连接数据和 LLM”做知识库 Agent 更顺手Semantic Kernel 对微软系技术栈更友好CrewAI 主要面向多 Agent 场景。到底选哪个我的看法是框架适合用来跑通原型和验证思路但在上生产前要想清楚哪些逻辑值得留、哪些抽象必须拆。举个实际例子早期用 LangChain 做客服 Agent最大的问题是你不知道模型每次调用之间到底传了什么上下文。框架默默帮你做了一些 prompt 拼接和记忆管理但它拼接的策略未必适合你的场景。一旦出现“模型不知道这个工具存在”这种问题排查起来得翻框架源码。后来我们只保留框架里最薄的那层——模型调用封装和工具调用解析——其他逻辑全部自己写。代码量确实多了但每个环节的输入输出都是可控的出了问题看一眼日志就能定位。所以我的建议是如果你在这个领域还是新手先用框架跑通一个最小 Demo理解它帮你处理了哪些事情等你对每个环节都有把握了再逐步把框架替换掉。把框架当教程和参照物而不是当信仰才是做工程该有的态度。2.4 决策点四记忆分层与持久化方案记忆系统在设计时我习惯把它拆成三层来考虑会话记忆、用户画像记忆、业务事实记忆。会话记忆就是本次对话的上下文通常存 Redis设置 24 到 48 小时的过期时间用户画像记忆是跨会话的偏好信息存数据库按用户维度组织业务事实记忆是用户问了哪些具体事实、产生了哪些结论这类往往需要向量化后存进向量库便于按语义检索。三层不能混在一个存储里。我曾经见过一个项目把所有记忆都往 Redis 里塞结果 Redis 内存一路飙到几个 GB原因就是历史会话没有过期策略脏数据越来越多。后来改成“热数据留 Redis、冷数据进数据库、检索场景才进向量库”之后资源占用立刻降了下来。检索策略上不要迷信“纯向量相似度”。工程上更稳的做法是“关键词过滤 向量召回 时间衰减”先按用户 ID、业务类型把候选集过滤到很小范围再做语义召回最后对召回结果按时间衰减排序。这套组合拳比单纯向量检索准确率高不少而且实现成本并不高。3. 深入关键决策上下文、工具协议与运行鲁棒性前四个决策点解决的是“Agent 长什么样、用什么搭”的问题从第五个决策点开始进入“Agent 跑得好不好”的深水区。这个阶段最考验功力因为很多坑不是看文档能避开的只能靠调试、观察、修 bug 一点点填平。3.1 决策点五Token 预算与上下文窗口的工程管理如果说记忆系统是数据的“后台存储”Token 预算就是数据的“前台带宽管理”。那什么是 token 预算就是给你的每次模型调用设定一个 token 使用上限并严格规划 prompt 里各部分的占用比例。没有预算的 Agent就像没有限额的信用卡你不知道它什么时候会把成本刷爆。以一个大模型常见的 128k 上下文窗口为例可以按这样的结构做预算分配核心系统提示词固定占用 4k 到 6k工具描述占用 3k 到 8k取决于你接了多少工具用户输入和当前任务占 8k 到 16k历史对话采用“保留最近 10 轮 之前部分做摘要”的策略控制在 20k 以内最后为模型输出预留 8k 到 16k。这样算下来实际上下文占用大约在 50k 左右剩余的全是余量。为什么要留余量因为 Agent 执行过程中每轮工具返回结果也会消耗上下文没有余量第二轮就会碰到 max_tokens 截断模型只能生成一半内容就开始胡说。对于生产环境的 Agent我强烈建议做 token 使用监控。每个 trace 里记录输入 token、输出 token、单次任务消耗总量以及工具调用返回占用的 token。上线两周后拉数据看哪类任务 token 消耗异常一眼就能定位。还可以做一些工程上的省钱操作对高频复用的工具描述做“预热缓存”对历史对话做摘要压缩后再放入上下文对模型已经成功执行过的步骤做缓存不再重复调用。这些手段叠起来一个长链路 Agent 的成本能降 40% 到 60%。3.2 决策点六工具协议从 JSON Schema 到 MCP工具定义得规不规范直接决定 Agent 能不能正确调用。我见过不少项目为了让 Agent 调用内部服务给每个系统单独写一个 tool adapter结果系统一多adapter 也跟着多维护成本直线上升。这个问题的根源是工具协议不统一。先讲基础最小的工具协议是一个 JSON Schema描述工具名、参数类型、必填项和返回值结构。用这套定义生成 function calling 的接口交给模型模型按约束输出调用参数。每个工具都遵循同一个 JSON Schema 规范整个 Agent 的工具层就是自洽的。进阶方案是 MCP。MCP 是一个专为 AI 应用设计工具连接标准协议解决多系统、多工具统一接入的问题。它让 Agent 不再需要为每个内部系统写专有的 adapter而是所有工具都暴露成同一种协议接口Agent 侧直接用标准客户端接入。我把 MCP 理解成 AI 世界的 USB-C 接口——过去每个工具一根线现在一根线通吃。做工具协议时要记住一个铁律工具描述里必须写清楚错误场景。比如“发送消息”这个工具你必须说明“消息内容为空时返回 40001 错误”“被限流时返回 429 错误”。因为 Agent 在遇到错误时会读错误信息来做下一步推理错误信息越明确它的应对策略就越准确。3.3 运行鲁棒性状态管理、重试与幂等控制Agent 是一个会循环执行动作的系统这意味着它必须有状态管理——当前执行到哪一步、这步的状态是成功还是失败、已经尝试了几次。没有状态管理的 Agent很容易在遇到错误时无限循环。工程实现上有三个必须设置的控制参数最大循环步数、单步超时时间、整体任务超时时间。以一次信息整理任务举例我一般设置最大循环步数为 12 步单步超时 30 秒整体任务超时 3 分钟。达到上限后强制终止任务返回“任务未完成已达最大重试次数”的明确错误而不是让 Agent 自己无限跑下去。幂等控制是另一个经常被忽视的点。什么是幂等就是同一个操作执行多次产生的结果和只执行一次是一样的。比如“创建订单”这个工具如果 Agent 超时后重试可能会创建两个订单——这就是没有幂等控制。解决方法是给每个任务生成一个唯一的事件 ID工具执行时先检查这个 ID 是否已经处理过处理过就直接返回上次的结果。还有一个很多团队踩过坑的地方Agent 的“空转”。表现为模型一直在调用同一个工具、传同样的参数、得到同样的结果然后继续调用。原因通常是工具返回的内容让模型觉得“还没完成”但模型又想不出别的办法。应对策略是加一个重复检测如果连续三轮出现完全相同的工具调用强制打断并把控制权交还给用户。4. 部署、可观测性与端到端案例前面讲的都是 Agent 内部的工程实现但一个 Agent 系统最终要给用户用部署形态、可观测性、评测回归这些最后一公里的问题才是决定项目能否长期稳定跑下去的关键。4.1 可观测性与评估没有日志和评测就别谈稳定Agent 应用和传统 Web 应用最大的区别在于它不是“请求进来响应出去”这种确定性的处理过程而是多轮推理、多步工具调用的动态流程。这就导致 Agent 出了问题时你很难判断是提示词的问题、模型的问题、工具的问题还是上下文被撑爆了。我的做法是给每个 Agent 请求记录一份结构化 trace包含用户的原始输入、Agent 每一轮的 thought、每一步调用的工具名和参数、工具返回值、模型原始输出、本轮消耗的 token 数、每步的耗时、最终是否成功。这份 trace 是排障的第一手证据也是评估系统的数据来源。没有它排查 Agent 问题就像在一间黑屋里找一只黑猫。评估这块我会从真实请求里抽出 30 到 50 条有代表性的任务人工标注出“正确答案”和“正确路径”组成回归评测集。每次改提示词、换模型、改工具定义后先跑一遍回归集对比新旧版本的任务完成率变化。这里有一个容易被忽略的技巧评测不仅要看最终结果对不对还要看路径对不对。一个 Agent 虽然最终给出了正确答案但中间多绕了三次无意义的工具调用这说明提示词还有优化空间。4.2 部署形态从脚本到服务集成进 Django 这类 Web 应用到了部署这一步你首先要回答的问题是Agent 是作为离线批处理跑还是作为在线服务对外提供如果是离线任务比如每天定时整理数据、批量生成报告可以直接用一个定时触发的脚本包好跑完。但大多数业务场景需要在线响应比如用户在前端页面提问后端生成答案返回。在线场景下我强烈建议把 Agent 封装成一个独立的服务而不是把 Agent 的循环逻辑直接写进 Web 框架里。以 Django 举例有人尝试直接把 Agent 循环写进 Django 视图函数结果一个请求要等模型推理几十秒数据库连接、worker 进程全被占住稍微有点并发系统就卡死。正确的做法是 Django 只负责接收请求、返回“任务已受理”真正跑 Agent 逻辑的任务丢给消息队列再由独立的 worker 进程消费执行完把结果回写到数据库。前端通过轮询或 WebSocket 轮询任务状态。部署时还要设置好限流和鉴权。Agent 服务的每个请求背后可能是多次模型调用和多次工具调用成本是普通接口的几十倍不设限流很容易被一个刷接口的脚本拖垮。云厂商的 Agent 工程化白皮书里也提到过类似的平台化思路强调要用网关统一收敛流量、做配额管理和审计。这些建议在自建系统时同样适用。4.3 端到端案例让小红书自动发消息的 Agent 是怎么拆解的最后拿一个具体案例把前面所有东西串起来。假设需求是“做一个 Agent让它自动在内容平台上发布消息”这个需求听起来很简单但拆解后涉及不少环节。目标拆解为五个动作接入素材库获取内容、生成适配风格的文案、准备配图并处理格式、调用平台接口发布消息、记录发布结果并处理失败。对应到七要素上模型负责文案生成和任务规划工具定义里有“获取素材”“生成文案”“上传图片”“发布消息”四个工具记忆系统负责记录哪些内容已发布避免重复发送安全边界里设置“发布消息”为高风险动作默认每次需要人工确认。工具协议定义示例tools [ { name: publish_post, description: 在指定平台发布一条新内容。若标题超过20字或正文超过1000字会被平台拒绝返回错误码 40003。若账号被限流则返回 429001。, parameters: { type: object, properties: { title: {type: string, description: 内容标题不超过20字}, content: {type: string, description: 正文内容不超过1000字}, image_urls: {type: array, items: {type: string}, description: 配图URL列表最多9张} }, required: [title, content] } } ]在工程落地时有一个容易忽略的成本问题。Agent 每执行一次完整发布任务可能会调用模型多次第一轮生成文案第二轮检查文案是否符合平台字数限制第三轮处理图片 URL最后一轮才调用发布工具并确认结果。按单次任务消耗 5 到 10 次模型调用、每次调用消耗 1500 到 3000 个 token 来算单个任务成本约在几毛钱到几块钱的区间。如果不控制质量和失败重试次数成本还会往上翻。更稳的方法是对 Agent 生成的文案做一次自动校验不满足字数限制就先本地处理再发布而不是直接让模型在循环里自己改。这类自动发布任务还会遇到平台频率限制、登录态过期、图片格式不被支持等实际问题。给 Agent 设置合理的重试逻辑和终止条件是刚需配置“连续失败 3 次后停止任务并通知管理员”比让 Agent 自行反复尝试更稳妥。写成具体的工程参数就是对每个失败原因设置最大重试次数发布失败后回写状态并保留人工介入的入口。这个案例看起来简单但把它完整跑通并稳定运行需要的就是前面那一整套要素和决策点的落地。你在实际项目里遇到的大概率也是一个类似的具体业务场景无非是素材不同、平台不同、约束不同。把业务塞进这套框架里拆一拆很多“不知道从哪下手”的问题就已经解决了一半。我自己在实操中的体会是Agent 的能力边界不由模型单独决定而由你愿意给它接多少工具、你能否兜住它的错误、你能否让它在自己控制的轨道里自主行动共同决定。框架会换API 会变模型迭代一轮比一轮快但这七个要素和七个决策点背后的思辨方式短期内不会过时。把这套方法吃透了以后再遇到任何 Agent 相关的需求你就不是抄一个 Demo而是真正在做工程了。