一、定义边界
明确任务边界是构建Agent的第一步。需要回答：
· 具体要解决什么问题
· 输入输出格式是什么
· 操作权限范围
· 任务完成的判定条件
没有清晰边界的Agent，后续所有工作都建立在流沙之上。
二、工程目录
定义规范的工程目录结构，包括README、Git版本控制、环境变量管理等。特别注意API Key的安全管理，避免硬编码泄露。
三、定义Agent
定义Agent的核心要素：角色、目标、规则、可用工具、输出格式。Agent的定位要从模糊的想象收敛到具体、可落地、可量化的范围。
四、Tools
一个工具只负责一件明确的事，输入输出要规范。工具调用需要设计严格的接口约束，避免Agent随意调用导致不可控行为。
五、Skill
区分Tool和Skill：Tool是执行能力（如搜索、计算），Skill是完成任务的方法（如"如何撰写市场分析报告"），具有复用价值。
六、状态和记忆
· Context（上下文） ：负责当前任务的临时状态
· Memory（记忆） ：负责长期沉淀的知识
两者分离设计，避免上下文膨胀导致Agent"失忆"。
七、Prompts
分层定义Prompts，降低改动成本。将Prompt纳入Git做版本控制，确保每次变更可追溯、可回滚。
八、评测：
建立量化评估体系，核心指标包括：
· 事实准确率
· 工具选择正确率
· 任务完成率
Demo展示的是Agent的"上限"，而生产系统需要保证的是"下限"。
九、部署和监控（10:59）
确保系统的可观测性，通过trace链路定位问题。每一步决策都要有迹可循、可审计，出错时能优雅降级而非直接崩溃。
十、核心设计理念
采用Plan-Execute-Verify（PEV）模式替代纯ReAct模式：Plan阶段生成可校验的执行计划，Execute阶段逐步执行并记录状态，Verify阶段验证结果决定是否继续/重试/降级。ReAct模式适合Demo，但生产环境下不确定性太高。