最近几个月我几乎每周都会收到同一种提问AI Agent到底怎么落地不少人看完各种白皮书、拆过七要素、跑过示例代码可一旦要自己做工程实现还是卡在原地。我仔细观察过这些“卡住”的人发现他们缺的不是资料而是一张能把“概念”翻译成“决策”的表格。这篇文章想解决的就是把Agent从七要素一路拆到七个决策点说清楚哪些地方必须拍板、每个决策背后有什么代价以及落到工程代码里应该长什么样。适合正要动手搭建Agent、又不想只是把Demo跑通就完事的读者。1. 七要素拆Agent之前先承认它是一台机器1.1 七要素全景哪七个零件支撑起一个AgentAgent之所以让人觉得“玄”是因为宣传稿总喜欢把它说成一种有自主意识的东西。工程视角下更稳妥的理解是Agent是一台由七个零件组成的机器缺了哪一个行为都会不对劲。我通常按这七个要素拆解大语言模型LLMAgent的“大脑”负责理解任务、生成计划、产出动作指令。规划Planning把一个大目标拆成可执行的小步骤决定先做什么、后做什么、什么时候停。记忆Memory当前任务的上下文叫短期记忆跨任务沉淀的业务知识和历史结果叫长期记忆。工具Tools模型外部的能力比如搜索引擎、数据库查询、代码执行器、第三方API。环境EnvironmentAgent感知和操作的真实对象可以是网页、操作系统也可以是某个业务系统。行动Action模型最终输出的可执行指令它需要被翻译成真正的函数调用或界面操作。反馈Feedback / Reflection观察行动结果判断成功或失败并把结论带回下一步决策。这个抽象不是哪一家公司定的标准而是从各家框架里抽出来的公共结构。无论是Function Calling的调用循环、LangGraph的节点与边、AutoGPT的无限循环还是各种云厂商白皮书里的架构图底层都能映射到这套框架。先把七要素认定为一台机器的零件后面才有真正的工程讨论否则我们聊的只是“调用大模型接口”。1.2 用一个“内容发布Agent”把七要素串着讲概念光靠定义很难有感觉我用一个具体场景串一遍假设你要做一个Agent每周五从素材库里取出原始资料自动写成一篇带图的短文定时发布到自己的内容账号上。这里默认一个前提使用的是平台开放的API、在自己的授权账号范围内操作发布前有预览和审批。LLM负责把素材库里的原始信息改写成通俗文案并起标题规划要做的是把“读素材→生成文案→生成配图→存草稿→送审→定时发布→记录结果”拆成有序步骤记忆负责记住历史发布记录让模型知道“上周已经发过优惠话题这周不要再重复”工具包含素材库查询接口、文生图API、内容平台草稿与发布API环境是执行这些调用的服务器沙箱以及平台上那个被授权账号的API凭据行动在代码里表现为一串结构化指令比如{type: draft, title: ..., content: ...}反馈在发布成功后把文章ID和阅读数据写回记忆失败时读取错误码并触发重试或降级。同一个例子你可以试着把用户点餐、客服工单、数据分析汇报都套进去会发现结构完全一致。七要素存在的意义不是让你背概念而是让你在工程上有个检查清单当Agent乱转的时候先确认是不是少了一个零件。2. 七个决策点要素本身不解决问题选择才解决问题2.1 决策总览表从要素到决策点的一一映射七要素是静态解剖告诉我们Agent“由什么组成”。但两个团队用完全相同的七要素写出来的系统效果可能天差地别差别全在七个决策点上。我习惯把每个要素对应到一个必须拍板的工程决策要素对应决策点一句话问题常见方案LLM1. 模型选型用哪个模型token预算怎么控制闭源旗舰 / 开源中尺寸模型 / 大小模型组合规划2. 推理策略一次规划到位还是循环迭代ReAct / Plan-and-Execute / 树搜索记忆3. 记忆策略上下文装得下历史吗装不下怎么办滚动窗口 / 向量库检索 / 摘要压缩工具4. 工具边界暴露哪些工具、怎么约束调用方式Function Call / MCP / 工具白名单环境5. 交互方式连原生API还是操作真实界面原生API / 浏览器自动化 / 沙箱行动6. 执行粒度与审阅自动执行还是人工确认后执行全自动 / 分步确认 / 强制审批反馈7. 闭环与护栏怎么知道行动做对了出错如何熔断Eval集 / 日志链路 / 输出过滤与限流这张表就是整篇文章的龙骨。后面的内容基本围绕“决策点怎么选、为什么选、选了之后有什么坑”展开。2.2 决策点一、二模型选型与token预算管理模型选型没有万能答案只有约束条件下的取舍。任务需要大量推理和工具调用时优先选上下文窗口大、Function Calling稳定的模型任务简单且实时性要求高时小模型反而体验更好数据敏感场景只能私有化部署开源模型。另一个常被忽视的思路是按任务拆模型主模型负责规划和成稿子任务交给更便宜的小模型例如把长文本摘要单独交给小模型做成本能降不少。这时候必须把token这笔账算清楚。很多人问“Agent的token是什么意思”其实token是模型处理和计费的最小文本单位英文一个词大约对应1到1.5个token中文一个字大约对应0.5到1.5个token具体看词表。Agent场景的token消耗量远高于普通聊天原因在于模型本身是无状态的它不会记住上一轮对话。每轮循环你都得把系统提示、工具描述、历史对话、新观察结果重新全部发送一次。我常用的估算公式是这样固定开销等于系统提示加工具描述加已有对话假设是2000 1500 3000也就是6500 token每执行一个动作还会产生新的观察结果约500 token。10轮循环下来总消耗大概是6500乘以10加上每轮新产生的上下文增长轻松超过七八万token。所以决策点二真正要回答的不是“选哪个模型”而是“怎么控制上下文膨胀”。我自己惯用的手段有三个第一把旧轮对话压缩成摘要后再放进上下文第二长期信息放向量库按需检索而不是全量塞入第三工具描述瘦身只保留本次任务可能用到的工具schema。三步操作下来token费用通常能压到原来的三分之一以下。2.3 决策点三、四推理策略与记忆分层推理策略我只会主推三种ReAct、Plan-and-Execute、树搜索。ReAct是“思考一步、执行一步、观察结果再继续”适合下一步强依赖工具返回结果的场景这也是Agent最常用的模式。Plan-and-Execute是先让模型列出完整计划再按计划逐步执行适合任务链很长但步骤相对固定的场景比如周报自动生成。树搜索Tree of Thoughts是让模型同时探索多条路径再汇总比较适合需要多方案择优的任务但延迟和成本都很高工程上要慎用。判断依据很简单任务的每一步是否依赖中间结果依赖就选ReAct不依赖就优先考虑Plan-and-Execute。记忆策略经常被高估。很多Demo里的“记忆”不过是把历史聊天记录原封不动塞给模型严格来说这只是话痨的聊天记录不是记忆。真正的记忆需要分层短期记忆只保留当前任务的关键上下文用滚动窗口或KV缓存控制长度长期记忆存放跨任务生效的业务知识用向量库或结构化表存储。更关键的一点是在你完成一个有价值动作之后要显式地“把结论写回记忆”。没有这个写回动作长期记忆就是个空库。另外记忆不是越多越好每一条记忆进入上下文都会挤占token并引入噪声所以要给记忆打标签、设有效期、按需检索工程上我习惯把有把握的结论打在“长期记忆”里把临时过程数据只留在当前会话。2.4 决策点五、六工具编排与环境交互工具不是“在Prompt里写一句你有哪些函数”就完事。每个工具本质是一份元数据名称、用途描述、参数schema、返回格式示例、所需权限。我踩过的坑是工具描述写得太含糊模型遇到什么任务都调用同一个工具。后来我的写法是描述里明确写上“何时用、何时不用、典型输入输出例子”模型乱选的频率立刻下降。工具之间的失败重试、并行调用、降级链路也要提前定义好。环境交互方式上优先原生API因为稳定、可审计API覆盖不了时才考虑浏览器自动化或GUI Agent方案但页面DOM一变就可能崩需要额外的维护成本。不管选哪种都要把高风险环境隔离出来涉及数据库写入的操作先走沙箱涉及对外发送的操作先进草稿箱。行动审阅的分级我用了很多年直接说结论检索和读文件类动作可以全自动写草稿、发内部通知类动作自动执行但留日志发布、付款、删数据这类不可逆动作必须人工审批。执行粒度上宁可把动作拆小也不要让模型一次生成一大段脚本直接执行脚本类指令务必在沙箱里先试跑。2.5 决策点七行动/审阅与反馈闭环执行之后必须有反馈否则Agent容易陷入“原地打转”。我印象很深的一次排错某个Agent总是重复发同一条消息查日志发现每一轮它都以为自己是第一次发送原因是发送成功的返回结果没有写回上下文下一轮它又从初始状态出发。修复方式很简单在每次执行后把动作状态加入消息队列模型就能看到“这个动作已经做过了”。反馈是否成功需要一个可判定的信号比如HTTP状态码、页面元素是否出现、数据库行是否变化不要靠模型“猜”。护栏设计我放在反馈这个决策点一起讲因为两者是配套的。输出层要加二次过滤防止模型把数据库里的敏感字段直接吐给用户调用层要加频率限制和异常熔断单次任务超过N轮就强制停止同时准备一份eval回归集用20到50个历史真实case每次改Prompt、加工具、换模型都整体跑一遍。没有这套反馈与护栏Agent在Demo里很聪明上线之后就变成事故发生器。3. 主流架构与语言选型别被白皮书复杂度吓到3.1 单Agent、编排式、多Agent怎么选市面上介绍的Agent架构简化后其实只有三种单Agent、编排式、多Agent协作。单Agent加工具一个循环处理所有知识、规划和动作适合任务边界清晰、决策链短的场景也是我推荐绝大多数项目起步采用的架构。编排式有一个主Agent负责拆任务和分配多个Worker各自处理专项技能适合技能差异很大的任务组合。多Agent协作则是每个Agent都有自己的角色、私有记忆和工具通过消息通信完成复杂业务流听上去很优雅但要处理协议、死锁、上下文隔离、状态同步一堆问题边际成本很高。很多云厂商和开源框架画出来的Agent架构图都极其宏大但真实落地项目里绝大多数都是从“单Agent加两个工具”开始的。这不是退步而是控制变量先把主链路打通再在压力点长出新结构。我见过一个项目花了三周设计五个Agent的沟通协议最后发现单Agent加三个工具两天就完成了80%的需求剩下20%靠人工兜底更划算。3.2 Rust为什么出现在Agent基建里热词里经常看到“基于Rust的AI Agent”这里要泼一点冷水Rust近年确实越来越多出现在Agent基建层但用Rust写Agent业务逻辑对多数团队并不划算。它进基建层的理由很实际Agent runtime是典型的高并发加高IO场景tokio的并发能力与内存表现比Python更稳Agent状态机的状态迁移用Rust的类型系统可以在编译期约束减少状态乱飞的bugRust编译成WebAssembly可以当插件沙箱让Agent安全执行第三方代码。更合理的工程切分是Rust负责写网关、运行时、沙箱这类基础设施业务编排层继续用Python或TypeScript因为业务层的迭代速度要求远高于执行性能要求。如果你的团队没有性能瓶颈没有必要为了“Rust”而Rust。技术选型跟着瓶颈走不跟热度走。3.3 Django这类Web框架在Agent服务中的角色热搜词里有“用AI Agent开发Django”这其实是个很自然的组合。Django适合做Agent服务的HTTP外壳自带ORM任务、日志、审批记录、结果数据都落在数据库里Celery负责消费Agent任务队列避免同步请求把进程卡死自带的Admin后台可以快速做成人工审批台。典型的调用链长这样HTTP请求进入Django API为了不让请求端等太久我通常先把任务写入数据库并投递到Celery队列Worker异步启动Agent循环每执行一个动作就写一条日志Agent里的每一步对用户可见这对调试和排障帮助很大。一个最小可用的Django工程里Agent相关代码建议这样组织myproject/ apps/ agents/ # Agent定义与编排逻辑 tools/ # 工具集合与参数schema tasks/ # Celery任务启动、重试、熔断 evals/ # 回归集、评分脚本白皮书里的架构图往往很长落到Django项目里核心其实就是一个循环加一张状态表。把循环里的每一步都做成可观测、可恢复、可审阅比画出一张漂亮的架构图重要得多。4. 从搭建到部署一条可复现的实现路线4.1 第一步跑通最小闭环我搭建Agent的固定顺序第一原则是“先闭环再完善”。最小闭环的定义是一个任务、一个工具、三轮以内能完成。具体做法是选一个窄任务比如“把这段素材改写成周报要点”定义一个工具函数比如从素材库按ID读取内容然后固定执行顺序加载系统提示调用工具拿到素材让模型生成结果返回。跑通三个真实case并记录输出这个闭环就算成立。这一步不要碰向量库、不要上多Agent、不要接WebSocket这些都是后补项。没有闭环之前任何花哨组件都会变成排查问题的干扰项。我见过太多人第一周就在纠结“用哪个向量数据库存记忆”结果核心的Agent循环还没跑通。4.2 第二步按什么顺序补齐要素闭环跑通之后后续要素按这个顺序补齐每一步都做回归验证阶段要补的要素产出物1LLM 工具 行动最小闭环脚本2规划循环 停止条件可连续多步的Agent3反馈eval集 日志可回归验证的Agent4记忆先短期后长期上下文稳定、回答连贯5环境沙箱 审批可接入真实业务的Agent6反思 / 自我修正能处理复杂任务的Agent每个阶段加的东西不能太多。加完规划之后先把前20个case跑一遍确认没有把已经能用的闭环跑坏再加反馈。跳步是Agent工程里返工率最高的原因。4.3 部署测试阶段的高频坑部署环节有几个高频坑几乎每个Agent项目都会遇到我直接列出来状态必须外置。Agent循环不能依赖进程内变量否则进程一重启任务就断了。任务状态、上下文消息、工具结果都要持久化到数据库或Redis。外部API会超时。模型响应和工具调用都有可能超过HTTP网关超时时间所以Agent任务必须异步化别在同步请求里跑完整个循环。token预算突然爆炸。常见原因是某个工具返回了超长内容比如把整个网页全文塞给模型。对工具返回值要做截断和摘要并在代码里设上限。日志不完整排错要命。每条动作至少记录模型名、输入token数、动作类型、请求耗时、返回结果、错误码。没有这些出问题时只能靠猜。输出要二次过滤。模型可能把数据库里的原始字段直接吐给用户输出层必须做脱敏和内容合规检查。防重复执行用幂等键。重试机制必须携带幂等键否则一次网络抖动可能导致重复下单、重复发布。这个坑在内容发布场景尤其致命。5. 完整案例用Agent驱动内容自动发布5.1 从一句需求到一张要素决策表案例回到第1章那个内容发布Agent。需求是内部知识库每周沉淀一篇“本周技术周报”Agent自动把素材改写成推文草稿并定时发布。这里必须强调合规前提使用平台开放API、账号已授权、发布前人工预览确认且在测试账号做完灰度再放量。我先画一张要素决策表让每个决策落到具体选项模型选型主模型负责成稿和工具调用小模型负责素材摘要控制成本。推理策略采用ReAct因为每一步是否继续取决于前面素材读出来的内容和草稿生成结果。记忆策略短期记忆只保留当前素材、当前草稿、审阅意见长期记忆记录历史标题风格和往期阅读数据。工具边界只暴露素材库查询、文生图、草稿存取、定时发布、数据统计五个工具。环境交互素材库与内容平台都走原生API执行容器放在内部沙箱发布动作走审批后定时任务。行动与审阅生成草稿自动执行发布动作强制管理员审批统计拉取全自动。反馈闭环发布成功后的文章ID、阅读数据写回记忆失败重试最多2次再失败降级为人工任务并通知管理员。5.2 核心代码Agent循环、记忆与审批下面这段代码是Agent循环的精简版刻意省略了具体模型厂商的参数方便你迁移到自己的项目。它的重点在于每轮都把工具执行结果追加进消息列表让下一个动作能看到上一个动作的后果遇到禁止直接执行的动作就停住等待审批。我用Python风格写MAX_LOOP 10 task load_task(task_id) messages build_initial_messages(task, memory.recall(task)) for step in range(MAX_LOOP): resp llm.chat(messagesmessages, toolstool_schema) action parse_action(resp) # 解析结构化动作 log_action(action, stepstep) # 记录模型名、token数、耗时 if action.type finish: break if action.type in APPROVAL_REQUIRED: # 发布、删除等动作必须人工审批 save_awaiting_action(task_id, action) notify_admin(task_id, action) break result dispatch_tool(action) # 真正调用工具 messages.append(observe_message(action, result)) # 关键把反馈写回上下文 save_state(task_id, messages, step) # 状态外置宕机可恢复代码里最容易忽略的是observe_message(action, result)这一行。它把“你刚刚做了什么、结果是什么”显式放进模型可见的消息列表。很多Agent原地打转就是因为少了这行模型总以为自己什么都没做。审批逻辑也值得注意APPROVAL_REQUIRED集合里放的是发布、删除这类不可逆动作遇到就停下来存库而不是继续往下走。5.3 调优记录一个“反思型Prompt”带来的改变上线第一周这个Agent生成的草稿总被用户反馈“太像模板”。我一开始以为是模型能力不够后来在eval集上做了对照发现问题出在Prompt结构系统提示只有一句“写一篇技术推文”模型没有检查标准。我加了一段反思指令要求模型成稿后自己检查三个问题标题是否指向具体对象而不是空洞形容正文是否把最关键结论放在前三句行动指引是否明确、能否直接执行这个“反思”本质上多了一次自我检查的LLM调用token成本增加了一轮但对内容质量的影响很直接。不过我也要提醒不是所有任务都适合加反思。我把它用在另一个数据清洗Agent上效果反而变差因为数据清洗需要的是确定性规则不是自由发挥。决策点七的正确用法是在eval集上做A/B验证而不是照搬别人的Prompt。这个案例做下来最有价值的收获也不是那篇Prompt而是那张要素决策表——它让每一次调优都有据可查知道改的是哪个决策点影响了哪些环节。我自己有一个坚持了很久的习惯接手任何Agent项目第一件事不是看它用了什么框架、调了什么模型而是先画一张表左边写七要素现在各是什么右边写七个决策点分别怎么选的。画不出来的地方就是整个架构里最危险的地方。等你动手画完第一版通常会发现自己根本不需要一上来就上多Agent也不需要把工具堆到二十个。先把那一条从行动到反馈的闭环跑通让每次失败都能被看见、被修正比什么都重要。这才是Agent工程实现里最硬的一条经验。