AI Agent 创建实践
从场景定义、工作流与 agent 的选择、知识接入、能力扩展到评测验证，整理 AI Agent 的常见创建流程与实践要点。
#ai
#howto
#growing
[!info] related notes
AI Agent 创建实践
适用范围
这篇笔记记录的是“如何从零搭建一个可用 Agent”的通用实践，包含我做文旅场景智能体时沉淀下来的流程和判断方式。
一句话定义
创建 Agent 的关键，不是先堆模型能力，而是先定义任务边界、接入必要知识和工具，再通过评测数据不断校准效果。
先确认是不是一定要做 Agent
不是所有 LLM 应用都值得直接做成 agent。
更稳妥的顺序通常是：
- 先尝试单次调用 + 检索 + 示例
- 不够稳定时，再升级成 workflow
- 只有当路径难以写死、工具反馈很多、需要模型持续决策时，才进一步上 agent
这类判断的关键不是“功能看起来酷不酷”，而是复杂度增加后，效果是否真的显著变好。
先分清工作流和 Agent
- 工作流：步骤提前编排好，按固定流程执行
- Agent：模型能根据目标、工具结果和上下文持续拆解并推进任务
如果任务的子步骤和顺序都很清楚，优先考虑 workflow，通常更可控、更便宜、更好调试。
Agent 的基本构成
LLM：负责理解、推理和生成Tool：负责调用外部能力Runtime / State：负责执行循环、权限、预算、停止和必要状态Memory：按需保留跨任务信息，不替代运行状态与业务事实Knowledge：负责补充领域信息Evaluation：负责验证效果是否达标
底层常见起点其实不是“完整 agent”，而是 Augmented LLM。
Memory 不是只有历史消息
在 coding agent 里，Memory layer 往往至少会分成三层：
- 会话内状态
- 项目级记忆
- 用户级偏好和规则
缺少可恢复的项目上下文时，Agent 可能反复查找相同信息。项目文件、显式指令和工具查询也能恢复上下文，不一定需要另建长期记忆库；保留的信息仍需核对时效和来源。
一个实用的创建流程
- 先定义场景目标和边界，明确它要解决什么问题
- 列出需要什么知识、工具、数据和权限
- 设计角色设定、输出格式和约束规则
- 接入知识库、检索或业务系统能力
- 准备评测数据，验证准确率、稳定性和可解释性
- 根据失败样例迭代 prompt、工具和流程
验证与退出条件
- 用预先审定的代表性任务与失败场景检查输出、工具效果和来源；不要只看回答是否流畅。
- 验证权限拒绝、工具超时、预算耗尽和取消时的终态，确认没有重复副作用或误报完成。
- 记录配置、测试集与运行结果；未达门槛时回到对应失败层调整，再复测受影响场景。
常见 workflow 该怎么选
如果已经确定需要 multi-step system，可以先从这些模式里选：
- Prompt Chaining：任务能拆成固定顺序步骤
- LLM Task Routing：不同输入该走不同路径
- LLM Parallelization：想用并行换速度或置信度
- Orchestrator-Workers：子任务边界事先难写死
- Evaluator-Optimizer：结果需要多轮打磨
我在文旅场景里的经验抽象
- 先明确领域问题，再补知识，而不是先上传一堆资料
- 需要数值分析的问题，最好接数据库或结构化数据源
- 需要政策建议的问题，要把来源和依据展示出来
- 没有评测集时，Agent 很容易看起来能用，实际上不稳定
常见误区
- 把 Agent 当成“更会聊天的模型”
- 没区分 workflow 和 autonomous agent，导致过度设计
- 没有能力边界，什么问题都想让它答
- 只有知识库，没有验证闭环
- 工具和权限接得太重，结果维护成本过高
- 只调 prompt，不认真设计工具接口和 ACI
- 没有明确 停止条件，让 loop 在错误路径上无限重试
最短记忆方式
先定边界，再接知识和工具，最后用评测把 Agent 调稳。
Digital Biome