1. 目标
知识点讲解Agent 要有明确完成标准。
老师板书
目标
Agent
Agent 先要知道终点，才不会忙错方向。
先用人话讲明白
Agent 的目标是它要完成的可验证结果。目标必须具体，否则 Agent 会把“努力做事”误当成“完成任务”。
类比可以把它理解成给 AI 安排一套受控工位：有流程、有工具、有审批。
为什么要学定义 Agent 完成什么，而不是让它忙起来。
把关键词拆开看
- 结果导向：目标描述最终产物，而不是过程愿望。
- 可验证：完成后能检查是否达成。
- 边界明确：哪些事不属于本次任务。
入门版理解：Agent 要有明确完成标准。
适用范围和边界
1. 优先原则：先满足前提，再谈使用
在实际工程里，任何概念都不能脱离场景硬套。学习「目标」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。
- 先看它服务的专业判断是不是「Agent」：定义 Agent 完成什么，而不是让它忙起来。
- 任务目标可验证，步骤可拆分，工具输入输出可校验。
- 每个工具都有权限、参数范围、错误处理和审计记录。
2. 引入边界：同时满足这些条件，才值得推进
只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。
- 当「目标」能改变自动拉日志、检索已知问题、创建工单、查询构建、生成复盘草稿里的设计、评测或风险控制动作时，才值得进入方案。
- 适合多步骤、需要查资料或调用系统、重复发生的任务。
- 适合把日志查询、知识检索、工单创建、构建查询等内部能力安全接给 AI。
3. 反向边界：这些情况先停下来
专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。
- 目标过大时要拆成子任务。
- 目标不清会导致 Agent 乱调用工具。
- 不要让 Agent 处理目标含糊、工具危险、权限不清的任务。
- 不要暴露万能工具，例如任意 SQL、任意文件写入、任意线上配置修改。
- 工具调用有副作用，错误参数可能造成重复工单、错误通知或配置事故。
4. 上线前判断：能回答这些问题再落地
- 能画出 Agent 流程：目标、步骤、工具、参数、确认点、失败分支。
- 能为每个 Tool 写 Schema、权限、最大范围、超时和返回结构。
- 现场追问：如果工具调用错了、权限过大、参数不完整，系统会停下来还是继续犯错？
架构师总结：Agent 先要知道终点，才不会忙错方向。 对架构师来说，目标 不是一个要背的名词，而是一把判断尺：先看前提是否成立，再看收益是否大于复杂度，最后看失败时有没有证据、兜底和责任人。
通用例子：先脱离技术看懂它
“分析这批反馈并生成前三类问题及证据”比“帮我看看用户反馈”更适合作为 Agent 目标。
这个例子要看见的重点：定义 Agent 完成什么，而不是让它忙起来。 所以例子不是为了记故事，而是为了训练你在新场景里做同类判断。
投影 / Android 实战推演
- 业务推演：投影 Android 业务里，Agent 目标可以是“读取最近 24 小时崩溃日志，聚类 Top 5 问题，生成对应 Jira 草稿和证据链接”，而不是“优化质量”。
- 你要补的证据：围绕「Agent」列出数据、文档、日志、用户反馈或人工标注，避免只凭感觉判断。
- 可交付物：沉淀 Agent 任务设计、工具参数、权限矩阵、确认机制和验证样例。，让同事能照着复用，而不是只听你口头解释。
- 验收指标：至少选一个质量指标、一个效率指标、一个风险指标；比如正确率/一次解决率、定位耗时/追问轮次、误导用户率/转人工率。
- 迁移能力：同一套思路也能迁移到客服、测试、研发效率、运营分析和产品决策，不局限于投影业务。
老师会这样检查你是否真会了
- 你能不能用一句人话解释「目标」，并说出它解决的是「Agent」里的什么问题？
- 你能不能举一个适用场景和一个不适用场景，并说明边界来自数据、流程、风险还是权限？
- 你能不能把它落到一个真实小任务：输入是什么、输出是什么、验收指标是什么、失败时谁兜底？
- 老师追问：如果工具调用错了、权限过大、参数不完整，系统会停下来还是继续犯错？
- 练习产物：把一个模糊自动化需求改成包含交付物、验收标准、截止条件的 Agent 目标。
精通标准：Agent 先要知道终点，才不会忙错方向。 能精通的人，不是能背定义，而是能把它迁移到一个新业务里，写出判断表、数据要求、风险边界和落地动作。
业务判断方法
目标模糊时先做人工流程梳理。