基于大模型 llm 的 agent 应用开发

很多人第一次做 Agent，卡的不是模型选哪个，而是「一圈跑下来结果飘、钱还烧得快」。这篇不讲概念科普，按开发顺序把一件事拆成四段：先定任务边界与成功判据，再定工具和状态放在哪，然后压成本和延迟，最后做评测与上线回退。每一段都给出该确认的清单和「什么情况下这套做法不适用」。

很多人第一次做 Agent，卡住的不是模型选哪个，而是一圈跑下来结果飘、钱还烧得快。问题基本都出在开发顺序上：先纠结框架和模型，最后才发现任务边界没定、成功判据没写、循环没有终止条件。换个顺序做，先钉死任务和判据，再决定工具、状态放哪，然后压成本和延迟，最后做评测和灰度上线，返工次数会少很多。

下面按开发顺序拆成四段，每段给出该确认的清单和判断标准，也写清楚什么情况下这套做法不适用。不讲概念科普，只讲你打开编辑器之前和之后该做的动作。

第一步：先把任务边界和成功判据钉死

先判断这活到底该不该做成 Agent。步骤固定、输入输出确定、中间不需要看外部反馈的流程，用单次调用或者固定工作流更省更稳。只有需要多轮观察、结果不确定、要边做边改的场景，才值得上循环。判断标准很简单：如果人能一次把步骤写完并且不用回头改，那就不需要 Agent。

• 写下三条判据：什么算成功、什么算失败、允许重试几次。判据不写清，后面调参就没有参照，只能凭感觉换模型。
• 把动作分成「能做错的」和「不能做错的」两类。查询类可以自动跑，写操作类（下单、发消息、改文件、调外部接口）默认单独审批。
• 给每个任务写好「结束条件」，包括正常收敛和主动放弃两种。跑飞的第一步永远是「没有终止条件」。
• 判据里带上人可读的样例：一条成功记录长什么样，一条失败记录长什么样，方便后面做回归集。

第二步：回路、工具和状态分别怎么放

回路只负责三件事：看当前信息、决定下一步、把结果写回状态。这三件事之外的东西都别塞进循环里。控制循环次数上限，并且给每次循环打上编号，出问题时能按编号回放。工具接入选「少而稳」：每个工具要有明确的入参描述和失败返回，宁可多分几个窄工具，也别做一个万能函数让模型猜参数。

框架层面别耗太久，先对齐可选项再动手。可以参考站内的 Agent 框架与 SDK 目录 Agent 框架与 SDK 目录（/stacks/frameworks） 和 Agent 常用 API 清单（/stacks/agent-apis），按你的语言和部署方式筛出两三个候选，选一个直接开工。框架换来换去，真正影响成败的还是工具粒度和状态设计。

第三步：把成本和延迟压到能上线的水平

优化之前先测基线。接口延迟用 接口测速：先量出你的延迟基线（/tools/speed-test） 量，一轮任务的消耗用 模型成本计算器（/tools/model-cost-calculator） 估算。没有基线，你没法判断某次优化到底有没有用，只能凭感觉说变快了。基线要按任务类型分别记，不同任务的步数差异很大。

1. 拆小模型分工简单判断、格式整理交小模型，复杂推理再上大模型；改完用同一批任务对比通过率和消耗。
2. 压缩上下文每次塞进历史里的内容只留有用的，把工具返回结果做裁剪，验证方式是看同一任务输入长度是否下降而通过率没掉。
3. 加缓存重复的检索结果和稳定的判断结果缓存起来，在日志里确认命中情况，命中率低就把缓存键改细。
4. 并行化延迟敏感的场景把能并行的工具调用并起来，用测速页面复测端到端延迟。

具体的单价和用量行情变化快，去 官方 API 价格（/official-api） 和 真实用量榜（/usage） 核对当时的数字，别拿记忆里的旧值做决策。不适用的情况：一次性内部工具、每天只跑几十次，优化成本高于省下的钱，直接跑通就行。

第四步：评测、灰度与回退怎么安排

建一个小而固定的回归集：把真实跑过的任务按类型各留几条，每次改提示词、换模型、动工具都跑一遍，看的是通过率变化，不是单条输出好不好看。样本要覆盖你之前定的失败判据，否则测出来全是好消息。评测口径可参考 质量监控（/tools/quality-monitor） 与 质量检测（/tools/quality-check）。

• 日志记全：每一步的输入、工具返回、耗时和消耗，否则出问题只能重放。
• 回退方案在上线前写好，包括换回旧模型和关掉写操作两条路。
• 把每次上线的判据和实际结果留档，下一版改动有对照。
• 不适用的情况：探索性项目可以先靠人工看样本，等任务稳定了再补回归集。

Agent 的上线不是把循环打开就完事，而是把终止条件、工具边界和回退路径一起交付。