如何写一个 Agent
内容提要
本文介绍基于大模型构建Agent的方法：核心是“模型决策—程序执行工具—结果回传”的循环，需配置好Prompt、工具、上下文与记忆。文章给出Python最小实现，并强调保存完整输出、校验工具参数、设置停止条件。长任务需管理上下文，通过压缩历史保留目标与约束，但压缩有损，须能追溯原文。落地还需权限控制、超时重试、预算及可观测性评估。
延伸解读
Agent 与普通聊天程序的关键差异
文章指出，普通聊天程序处理“问题→回答”，而 Agent 多了一条“动作→结果→下一步动作”的反馈路径。模型负责提出工具调用，程序负责真正执行工具，两者不能混淆。这意味着 Agent 的可靠性不仅取决于模型判断，更取决于程序对工具调用的校验、权限控制和执行结果的处理。读者在动手实现时，应优先把执行循环和工具边界写清楚，而不是过度依赖 Prompt 来约束行为。
上下文压缩：有损但必要
长任务中，完整历史会持续占用上下文窗口，带来成本、延迟和干扰。文章建议在接近输入预算时触发压缩，将旧交互整理成结构化摘要，保留目标、硬约束、关键标识和事实来源。但压缩是有损的，摘要不能成为交易授权等事实的唯一来源，程序应单独保存关键状态并让摘要引用原始记录。评估压缩效果时，不能只看 token 减少量，还要比较任务成功率、约束遗忘和重复操作等情况。
从演示到可用：工程补全清单
最小实现只覆盖了执行循环，实际落地还需补齐权限与副作用控制、超时重试与预算、可观测性与评估。文章强调，有副作用的操作（如退款）需要业务授权和确认，确认应绑定具体参数；重试要区分查询与写操作，退款超时可能已成功，需用幂等键和状态查询确认。调试时至少记录任务 ID、模型调用耗时、token 用量、工具名、脱敏参数和结果、错误及退出原因，才能区分是选错工具、工具返回有误还是模型误读结果。
何时引入框架与多 Agent
文章认为，如果只是几个工具、一个短任务，用普通代码写清楚执行过程就足够。等到任务需要长时间运行、暂停等待人工确认、进程重启后继续执行，或多个步骤共享持久化状态时，再引入框架会更有针对性。多 Agent 也是如此，只有当任务确实可以拆成职责清楚、能够独立验收的部分时才值得考虑；多几个模型不会自动提高正确率，反而会增加上下文传递、结果合并和失败处理的成本。
Q&A
Agent 和普通聊天程序的核心区别是什么？
普通聊天程序主要处理“问题→回答”，而 Agent 多了一条“动作→结果→下一步动作”的反馈路径。Agent 的核心是一个循环：程序把目标、上下文和可用工具交给模型，模型决定下一步动作（调用工具或给出答复），程序执行动作并把结果回传模型，直到任务结束。
写一个 Agent 需要哪些组件？
一个实用的 Agent 通常包括：模型（理解输入并决策）、Prompt（描述职责和工作规则）、工具与执行器（声明能力、校验并执行调用）、上下文管理器（组织每次模型调用的信息）、记忆系统（保存并按需取回信息）、任务状态与调度器（跟踪进度、控制循环和退出条件）、观测与评估（记录轨迹、检验任务完成）。
如何设计 Agent 的 Prompt 和工具？
Prompt 要写清楚目标、事实依据（如以工具返回值为准）、工具调用时机、信息不足或失败时的处理方式、结束条件和答复要求。工具应有清晰的名称、描述和参数定义，边界明确；返回值应结构化，并区分“没有记录”和“服务不可用”等错误类型。
执行循环中有哪些不能省略的关键点？
不能省略：1) 保存完整输出（包括工具调用和 reasoning items），以便下一轮关联；2) 工具执行器要校验工具名、参数格式和业务权限，不能直接执行模型生成的代码；3) 设置停止条件（如模型返回文本或达到最大轮数），并明确循环结束不等于业务目标完成。
长任务中如何管理上下文和记忆？
上下文管理要按预算组装每次请求的内容，只发送当前步骤所需的部分，而不是全部历史。记忆系统需处理写入、检索、更新和删除，区分工作记忆、任务经历、长期事实与偏好、可复用流程。Context Compaction 可将长历史压缩成结构化摘要，保留目标、约束、关键事实和待办，但压缩有损，需能追溯原文。
从演示到生产，Agent 还需要补充哪些能力？
需要补充：工具的权限控制和副作用管理（如退款需确认）、超时/重试/预算控制（区分查询与写操作，使用幂等键）、可观测性和评估（记录任务 ID、耗时、token 用量、工具调用等，并针对固定任务测试模型行为）。当任务需要长时间运行、暂停恢复或持久化状态时，再考虑引入框架。
