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，而是真正在做工程了。
