如何开发一个 Agent：前置准备清单
开发 Agent 之前，最该做的不是急着写循环，而是把前置条件补齐。下面按“知识、环境、需求、最小闭环”四部分整理。
1. 前置知识
至少要能回答这些问题：
- LLM API 的输入输出结构是什么？temperature、max_tokens 会如何影响结果？
- 什么是 function calling / tool use？模型如何决定调用哪个工具？
- Prompt 里如何描述工具？参数格式和错误示例对调用成功率有多大影响？
- 什么是 RAG？检索结果如何与上下文拼装？
- 如何评估一次 Agent 输出是否“成功”？
如果这些概念还比较模糊，建议先做两个小实验：让模型稳定输出 JSON，再让模型根据工具描述调用一个真实 API。
2. 运行环境准备
一个最小可运行的 Agent 通常需要：
| 组件 | 作用 | 可选方案 |
|---|---|---|
| 模型服务 | 提供推理能力 | 厂商 API、本地模型、网关 |
| 工具接口 | 让 Agent 产生真实影响 | HTTP API、代码执行器、文件系统 |
| 状态存储 | 保存会话与长期记忆 | Redis、SQLite、向量数据库 |
| 可观测性 | 看每一轮在想什么、做了什么 | 日志、trace、回放面板 |
| 密钥管理 | 保护 API Key | 环境变量、密钥管理服务 |
建议一开始就记录完整 trace：模型输入、工具参数、工具返回、最终输出。没有 trace 的 Agent 很难调试。
3. 需求拆解
写代码前，先把产品需求翻译成 Agent 需求：
- 目标：Agent 到底要完成什么？用一句话说清楚。
- 边界：哪些场景必须支持，哪些明确不做？
- 工具清单：完成目标最少需要哪几个工具？每一个的输出如何被使用？
- 成功标准：什么算做对了？什么算失败？失败后由谁兜底？
- 数据来源：知识来自哪里？是否需要 RAG？文档权限如何控制？
这个阶段最容易犯的错是“工具越加越多”。工具越多，决策空间越大，模型越容易选错。
4. 最小闭环
第一个版本不要追求完整框架，先跑通最小闭环：
text
用户输入
→ 模型理解目标
→ 调用一个工具
→ 观察结果
→ 输出答案推荐开发顺序：
- 先做单轮：输入问题，返回回答。
- 加一个工具：让回答依赖真实数据。
- 加循环：结果不满足条件时继续追问。
- 加记忆：多轮对话能记住关键信息。
- 加评估：用固定用例回归，防止改坏行为。
5. 成本与安全的前置决策
- 给每轮循环设置最大步数，防止无限循环。
- 对工具调用做白名单，重要操作需要二次确认。
- 限制单次任务预算，超过上限就停止并提示用户。
- 用户输入和工具输出都做长度控制，避免上下文被撑爆。
最后
Agent 开发的门槛不在“调用模型”，而在把模型放进一个稳定、可观察、可控的系统里。前置准备做得越扎实，后面迭代越快。