我现在优化Agent只做这四件事 #howto用好AI[话题]# #AI反常识howto[话题]# #Agent[话题]#

最近我对 Agent 的优化速度发生了一个挺大的变化。 以前 Agent 一犯错，我的第一反应是改 prompt。他忘记测试，我就在 Agent 的 MD 里加一句：修改完成后必须执行测试。他没有先分析一下范围，我再加一句：动手之前必须先阅读相关代码。他完成任务以后没有认真验收，我就继续增加 planner、implier、verifier，给他设计一套更复杂的工作流。再后来我又开始不断增加 skill：怎么查日志、怎么分析代码、怎么生成验收清单、怎么输出任务总结，全部整理成规范。 看起来整个系统越来越完善，但模型升级几次以后，我发现一个最尴尬的问题：以前花大量时间打磨的东西正在快速贬值。很多过去必须反复提醒模型的事情，现在他自己就会做。他知道先搜索代码，知道分析调用链，也知道修改完成后运行测试。这时候你继续给他塞一大堆流程、示例和规则，不但没有明显帮助，反而可能限制它。一个简单的任务也要机械地输出长篇计划，明明模型有更好的解决办法，却因为 skill 里写了固定步骤，只能照着旧流程执行。 所以我现在优化 Agent，已经很少继续纠结 prompt 应该怎么写、Agent 的 MD 还要增加什么规则，我主要只做 4 件事。 第一件事，给 Agent 补充真实的业务上下文。 模型再强，也不可能天然制造你的业务。 它不知道你们的业务日期是按照自然日，还是按照门店所在时区的营业日计算。 它不知道某客户为什么存在特殊逻辑，也不知道哪个例子方案已经废弃。 它更不可能知道你们昨天开会做了什么决定。 这些问题不是因为模型不够聪明，而是因为它天然缺少事实。 所以我现在不会把大量精力放在教模型先做什么、再做什么。 我更关注的是，Agent 能不能准确地找到项目架构、业务口径、例子决策、客户规则和会议纪要。 重点也不是把所有文档全部塞进上下文，文档太多，反而制造噪音。 真正重要的是，当 Agent 遇到一个具体问题时，它能不能知道去哪里寻找权威信息。 所以我现在对 Agent 的 MD 的定位更像是一张地图。 它不需要教模型如何思考，只需要告诉它这个项目是做什么的，重要信息在哪里，哪些业务边界不能违反。 第二件事，把人工操作封装成工具。 以前我们很喜欢把人工操作写成 Skill。 比如排查一个问题，必须先登录日志平台，选择项目，输入查询条件，找到 SessionID，再顺着上下游日志一点点追踪。 我们会把整个流程写得非常详细，希望 Agent 能够模仿人工完成操作。 但这种 Scale 非常脆弱。只要日志阻断变了，查询如何变了，整份 Scale 都需要重新修改。所以我现在更倾向于直接给 Agent 提供一个工具。比如输入 SessionID，工具直接返回完整链路，每一个处理状态、相关日志、关键图片和异常节点。Agent 不再学习人是怎么点页面、拼查询语句的，它只需要根据结构化结果做判断。这也是我现在对 Scale 的理解，Scale 真正有价值的部分不是里面写了多少说明，而是背后有没有真实、稳定、可执行的能力。模型会越来越擅长调用工具，但它不会凭空拥有你公司的日志查询接口、数据库访问能力、数据回放环境和业务对比工具。所以与其继续优化工具使用教程，不如把工具本身做得更好。 第三件事，定义什么叫真的做对了，这是我最近感触最深的一点。之前我发现过一次很隐蔽的问题，Agent 修改的代码可以正常运行，接口没有报错，测试也通过了，但最后核对业务结果时，我发现它选错了业务日期。从技术角度看，任务已经完成，从业务角度看，结果是错的。这点问题是危险的，因为它不会让系统崩溃，只会安静地产生错误数据。所以我现在不再满足于要求 Agent 修改完成后记得测试，我会进一步要求它回答， 你拿什么证明这个结果是正确的？比如这次实际处理的是哪一天的数据，使用的是什么时期，结架日常经有没有覆盖，有没有重复处理。修改前后的业务结果有什么异常，日治里能不能找到完整的证据。 执行测试是一个过程要求，证明业务结果正确才是成功标准。模型能力越强，我们越不需要告诉它每一步具体怎么走，但我们必须告诉它，终点到底在哪里。这也是为什么我现在越来越重视业务评测级。 每出现一次真实错误，让它沉淀成一个回归场景。以后无论是换 Codex、Cloud Code，还是更强的新模型，它都有一套真实的业务问题去验证。 第四件事，让每次错误都进入反馈避缓。以前 ATM 的出错，我会往 ATM.md 里加一句，下次注意。现在我不会这么快加规则，我会先判断这次错误究竟发生在哪一层。缺少业务事实，那就不知是库；业务规则的业务错误，那就把它定义成业务不变两；那就改造工具；结果无法判断，那就增加验售标准；同类问题反复出现，那就加入回归评测级。只有当它真的是某一代模型的偶发问题时，我才会考虑修改 promet。因为一句下次注意，并没有真正解决问题，它只是把错误暂时压尽的上下文。真正有下子的变化，失败一次错误，变成永久的系统能力。 比如业务日期选错，最差的方案是在 atm.md 里加一句，注意选择正确的日期。稍微好一点是把业务日期的定义写清楚。更好的方案是提供统一的业务日期计算工具。再进一步是把这个错误加入自动验售和回归评测，保证以后所有相关修改都必须验证这个场景，这才叫反馈避缓。 所以现在我优化 adm 的主要只做四件事：一，补充真实的业务上下文；二，提供稳定的工具能力；三，定义清晰的成功标准；四，把每一次失败转换成反馈避缓。 至于 promot、admd 和 scale 的说明，我当然还会维护，但我已经不再把它们当成最核心的资产，因为这些东西更像是模型适配层，模型一升级，它就可能需要重新删减或调整。而业务上下文、工具能力、评测标准和反馈避缓，不会因为模型变强而失效，相反模型越强，它们的价值越大。 以后判断一下 adm 的优化值不值得做，可以先问自己一个问题：假如模型能力再增强 10 倍，这个东西还需要吗？如果答案是否定的，它可能只是在弥补当前模型能力的不足；如果模型聪明 10 倍后仍然需要，那它才更可能是真正的长期资产。 未来真正细确的不是让 adm 的任务做完，而是你能不能给它真实实节，给它合适的工具，并准确判断它到底有没有把事情作对。