第一次搭 Agent，最容易卡在模型和框架之间：Python 版本不对，依赖互相冲突，API Key 写进了代码，最后还没看清 Agent 做了什么就开始堆功能。
这本书把环境准备放在前面，我觉得很合理。一个可复现的最小项目，应该先解决“能运行、能观察、能停止”三个问题。
环境准备要可复现
建议先建立独立虚拟环境，固定 Python 和依赖版本，把配置与业务代码分开。项目至少应有：
agent-demo/
env-example.txt
pyproject.toml 或 requirements.txt
src/
tests/
README.md
配置示例文件只保存变量名，不保存真实密钥。真正的 API Key 放在本地环境变量或密钥管理服务里，绝不能提交到 Git。
第一个 Agent 不需要很复杂
一个 Hello Agent 只要完成一件小事就够了，例如根据用户问题判断是否需要调用计算器，然后返回答案。
用户问题 -> 模型判断 -> 计算器工具（可选） -> 最终回答
这个例子同时覆盖了模型调用、工具选择和结果回传，比单纯打印模型文本更能帮助我们理解 Agent 的基本闭环。
先定义边界，再写 Prompt
开始写代码前，我会先列出：
- Agent 的目标是什么；
- 允许使用哪些工具；
- 工具参数是什么类型；
- 什么时候必须停止；
- 出错时返回什么；
- 哪些动作必须由用户确认。
例如计算器工具只接受数字和运算表达式，不应该直接执行任意 Python；搜索工具只读取公开网页，不应该具备写文件权限。
第一次运行要观察什么
不要只看终端最后一句答案。至少确认：
- 模型是否真的选择了工具；
- 工具收到的参数是否符合预期；
- 工具结果有没有回到模型上下文；
- Agent 是否在合理轮数内结束；
- API 错误、超时和空结果有没有被捕获。
如果框架提供 Trace 或回调，第一次运行就打开。否则遇到错误时只能猜是 Prompt、工具还是模型出了问题。
准备几组边界问题
除了“2+3 等于多少”，还要测试表达式缺失、除数为零、用户要求执行危险代码、模型无法调用工具、网络超时和工具返回异常。
边界问题不是为了为难系统，而是为了确认失败路径已经被设计。一个只在 happy path 上成功的 Agent，还不能算完成。
这章给我的启发
第一个 Agent 的目标不是展示多强，而是建立一个可以重复运行的实验台。配置可管理、工具有边界、运行可观察、失败能停止，后面增加记忆和 RAG 时才不会失去控制。
从零开始学 Agent，第一步不是“做一个万能助手”，而是让一个很小的闭环真正跑通。
文章摘自：https://www.cnblogs.com/hazy-star/p/22627375
京ICP备14020293号-4