你可能已经看过不少 Agent 演示，真到自己动手时却卡在几件事上：模型该用官方 API 还是本地权重、工具调用怎么写才不崩、什么时候该微调而不是继续堆提示词、上线后延迟和成本怎么兜住。这篇不铺理论，按『先跑通再优化』的顺序给一条可执行的路径，每一步都标出该去站内哪个页面核对当时的数字，并说明什么情况下这条路不适用。
你大概看过不少 Agent 演示：能查资料、能调工具、能自己绕几圈把事办完。真轮到自己写，卡点往往不在理论，而在几件很具体的事上——模型用官方 API 还是本地权重、工具调用怎么写才不崩、什么时候该微调而不是继续堆提示词、上线后延迟和成本怎么兜住。这篇不铺概念，按「先跑通再优化」的顺序给一条动手路径。
下面每一节都标出该去站内哪个页面核对当时的数字，也说明什么情况下这条路不适用。别背任何单价或耗时，口径会变，动手前现查一次就行。
第一步：先把 Agent 的边界和骨架定下来
动手前先在纸上写清三件事：这个任务能不能被拆成有明确输入输出的步骤、失败时是人兜住还是必须自动兜住、有没有外部工具能替代模型自己算（检索、计算、代码执行都算）。这三条写不出来，说明你要的不是 Agent，是一个更好的提示词。
- 骨架只留四块：模型调用层、工具注册层、循环与终止条件、日志与回放；先用一个最小可跑闭环，别一上来就上多 Agent 编排
- 挑框架时重点看它怎么定义工具、怎么中断循环，而不是看谁的功能列表长，可对照 Agent 框架与 SDK 目录
- 任务没有可验证的成功判据时（比如开放式创意写作），Agent 循环只会放大不确定性，老实做单轮生成更划算
- 先给自己定一条验收线：什么样算跑通、什么样算跑歪，没有这条线后面调优全靠感觉
第二步：模型和调用方式决定后面一半的坑
把任务分成两档：需要多步推理和工具编排的走能力档位高的模型，只做分类、抽取、格式化的走小模型或便宜档位。混合路由是省成本最直接的一招，但前提是你能判断当前请求属于哪一档——判断逻辑本身要简单且可测。
| 考虑因素 | 倾向按量调用 | 倾向自建推理 |
|---|---|---|
| 请求量 | 波动大、不确定 | 稳定且可预测 |
| 数据合规 | 内容可出公网 | 数据不能出内网 |
| 延迟要求 | 能接受网络往返 | 对首 token 有硬要求 |
| 维护成本 | 不想管运维 | 有人力维护服务 |
要不要自建推理服务，先去 部署测算 按模型和量化档位估显存与并发，再和按量调用的口径对比。接口先量基线：用 接口测速 记下首 token 和整段生成的耗时，Agent 每轮都要调用，单次多一秒，十轮循环就是十秒。
单价和限速别背数字，去 官方 API 价格 和 开源模型比价 核对当时的数字。口径里通常包含缓存、批量、限速档位这些细节，只看一个总价很容易判断错。
第三步：工具调用与循环控制，崩就崩在这
工具描述是写给模型看的，不是写给人看的。参数类型、取值范围、失败时返回什么，全部写进 schema；工具返回统一成短 JSON，别把整段网页或整张表塞回去，上下文会被撑爆，模型注意力也会散。
- 定义工具 schema每个工具只做一件事，参数必填项尽量少，枚举值写全；写完用几组边界参数手工调一次，确认模型能构造出合法调用
- 加三道闸最大步数、单次超时、重复调用同一工具同一参数的检测；触发任意一道就退回给人或输出当前最好结果
- 落日志与回放每轮的输入、工具名、参数、返回、耗时都记下来，排错时先看从哪一步开始偏，而不是从头重跑
- 设失败特征参考 质量监控 的思路，挑几条能自动判断的失败特征，比如连续两轮工具无有效返回
- 想接现成的外部能力，先去 MCP 服务器大全 和 Agent 常用 API 清单 找，别自己从零写连接器
- 终止条件要写死：达到目标、步数用尽、连续失败，三种情况分别返回什么，提前定好
- 工具返回的错误信息也要结构化，模型才能据此换策略，而不是拿到一段人话报错后原地打转
第四步：什么时候才轮到微调
判断顺序是：先提示词、再检索增强、最后微调。格式不稳先改提示词和输出约束，知识不够先接检索，只有「风格或固定输出结构反复教不会」才考虑微调。这个顺序别跳，跳了容易花大力气解决一个本来改两行提示词就能解决的问题。
| 现象 | 先试什么 | 再考虑什么 |
|---|---|---|
| 输出格式不稳 | 输出约束与示例 | 微调固定结构 |
| 知识不够新 | 接检索或外部数据 | 补训练数据 |
| 语气风格不对 | 系统提示与少量示例 | 风格微调 |
| 任务边界还在变 | 先别动权重 | 等需求稳定 |
真要微调，先去 微调服务商目录 看托管方案，再评估自训。数据准备和显存估算分别对照 模型成本计算器 与部署测算页，把训练、合并、部署三段的开销一起算，别只算训练那一段。
微调完不是结束，还要走合并、量化、部署这条链，兼容问题常出在后半段，上线前留一次回退方案。数据量太少、任务边界还在变、或者基础模型本身就要换代，这三种情况下微调投入大概率白花，先把前面三步做扎实。
第五步：上线后盯什么，出问题按什么顺序查
上线只放三个核心指标：任务成功率、单次平均成本、端到端 P95 耗时。其余指标等这三项稳定再加，指标一多，出问题时反而不知道该看哪个。
- 排查顺序固定：先看模型接口是否降级或限速，再看工具返回是否变了格式，再看提示词是否被上游改动，最后才怀疑模型能力
- 成本异常时先确认计费口径是不是变了，定期去 价格变动追踪 和 厂商与平台目录 对一遍
- 走第三方中转的话，先用 中转站真假在线实测 确认服务真在线，再怀疑自己的代码
- 每次改动只动一个变量，成功率、成本、耗时三项至少留一项做回归对照
这套顺序的价值在于把排查范围逐层缩小。跳过前面几层直接调模型参数，往往是在给一个已经正常的东西做无用功。
Agent 的能力上限由模型决定，能不能稳定跑起来由循环和日志决定。下一步动手前先去站内把模型、框架、工具链当时的数字和方案对一遍，再决定走按量调用还是自建，能省掉后面大半返工。→
常见问题
一点机器学习背景都没有，能直接动手做 Agent 吗？
能，但要先把范围收窄：只做工具调用加循环，不碰训练。模型调用、工具 schema、循环终止条件这三块全是工程活，照着做就能跑通最小闭环。真正的门槛在数据准备和评估，等你要微调时再去补那部分知识，顺序反过来容易卡死在环境配置上。
Agent 效果不好，是该换更强的模型还是该微调？
先别动模型。按这个顺序排查：输出格式不稳改提示词和结构化约束，事实答错接检索，多步推理断裂改任务拆解和工具粒度。这三样都试过、失败模式仍然集中在固定的语言风格或固定输出结构上，才轮到微调，否则换了模型问题照旧。
本地跑模型做 Agent 和调 API，怎么判断该走哪条？
看三条硬约束：数据能不能出内网、请求量是否稳定到能摊薄卡的成本、延迟要求是否严到必须自己控。三条里有两条成立就自建，否则先调 API 把产品跑通。估算时别只看单卡租金，把并发、利用率和运维时间一起算进去，具体口径去站内的部署测算和算力页面看当时数字。
