Agent 使用技巧整理
BROKE 框架
BROKE 框架是一种常用的大模型提示词框架，它由五个部分组成：背景（Background）、角色（Role）、目标（Objective）、约束 (Key Constraints) 和示例（Example）。通过这个框架，我们可以更好地设计提示词，帮助大模型生成更准确和相关的内容。
| 要素 | 例子 |
|---|---|
| 背景（Background） | 你正在为一个大型电商平台开发一个新的用户界面，目标是提升用户体验和转化率。 |
| 角色（Role） | 你是一个资深的前端开发者，拥有10年的工作经验，熟悉各种前端技术和工具。 |
| 目标（Objective） | 设计一个简洁、直观且响应迅速的用户界面，能够吸引用户并促进购买行为。 |
| 约束 (Key Constraints) | 你只能使用React和Tailwind CSS来开发这个界面 |
| 示例（Example） | 这是一个React组件的示例代码，展示了如何使用Tailwind CSS来创建一个响应式按钮... |
需要注意的是：示例要么不写，如果写则必须要具体且准确，不能太抽象让模型猜测，否则模型可能无法理解你的需求。不好的示例可能会引导模型生成的内容不符合预期，甚至完全错误。
Bad:
"帮我写个Node爬虫。"
Good:
## 角色
你是一个资深的后端开发者，拥有10年的工作经验，熟悉各种后端技术和工具。
## 目标
请帮我写一个Node爬虫，目标是从一个电商网站上爬取产品信息，并将数据存储在MongoDB数据库中。
## 注意
请确保爬虫能够处理分页，并且遵守网站的robots.txt规则。
## 示例
以下是一个示例代码，展示了如何使用Node.js和Cheerio库来实现这个功能...AI 管理学
一. 不同的 TRM（Task-Relevant Maturity，即任务相关成熟度） 任务，使用不同的方式管理
- 高TRM任务，放手交给AI。如写模板代码、重命名变量、生成测试用例，这种完全可以一句话交给AI处理。
参考 swagger 文档，给所有 API 接口生成 TypeScript 类型定义- 中TRM任务，人辅助AI做。如BUG处理、单模块代码重构，这种我们需要提供一些信息，例如BUG的复现步骤、重构的目标和范围以及约束等等，这里也可以采用上面的 BROKE 框架来设计提示词。
搜索功能偶尔返回空结果，我怀疑是缓存过期的时序问题
你可以参考 src/services/search.ts 和 src/cache/redis.ts 这两个文件，分析一下可能的原因- 低TRM任务，AI辅助人做。如系统级的架构设计、跨多个模块的复杂功能、涉及技术选型的重大决策。这些一般我们需要通过详细的 plan 或 spec，分步来做。具体上我们可以先通过plan mode和ai沟通确定详细的方案，然后在分步执行。
对于 Plan Mode，我们可以
按照
分析 -> 讨论 -> 细节决策 -> 形成 Plan -> 分步执行的工作流来进行。txt请你先分析一下 [相关目录/文件] 的现有架构（梳理项目xxx功能的实现），主要涉及哪些模块，告诉我目前的数据流是怎么流转的。。 我想做 [简述你的目标]。 你觉得现有架构能不能支持？有什么需要注意的地方？ 请你跟我讨论一下每个实现细节。 我希望把所有的生成/迭代操作都变为一个 sub-agent 来做。 我们现在已经实现了 xxx 功能呢，可以尽可能复用。 对于 xxx 功能，我觉得可以使用 xxx 实现，你觉得怎么样？如果你觉得有问题，有其他备选方案吗？ 对于AI遗漏的信息，可以手动补充： 你说的 A 方案不太合适，因为 [你的原因]。 另外你漏掉了一个点：[补充信息]。 基于这些，你再想想呢？ 对于具体细节，可以提供关键决策： 关于 [决策点 A]，我选方案一，因为 [原因]。 关于 [决策点 B]，我的想法是 [具体说明]。 最终再总结执行Plan 好，基于我们刚才讨论确认的方案， 请你写一个详细的执行 plan。 在步骤执行上，可以使用 对于步骤/功能一，用 sub-agent 的方式来实现，把其中高TRM的子任务交给低参数模型来做，节省token和经费如果直接写 plan，AI 会自己默默做决策，把这些问题藏起来。但在讨论模式下，它会主动暴露问题，让你来判断。
使用多个高参数模型相互审阅其他模型的方案，最终产出一个综合了多个模型优点的方案。
txt1. 让 claude输出第一版方案 2. 把第一版方案扔给GPT，让它审查，并给出改进意见：你是一个优秀的xxx，我现在打算重构 xxx，这是我的方案，请仔细检查每一个模块，并给出审查意见，对于一些你觉得不合理的地方，请给出改进建议，最后请你总结一下你的审查意见。 3. 这是我的审查意见，请参考意见给出你的第二版方案。 4. 如果方案没问题，再根据方案实现详细的编码实现方案，否则继续审阅 5. 最后把详细的方案专门交给另一个AI（单一原则，可以新开agent）来执行同一个 AI 会对自己的产出比较盲目自信，如果让它自己审阅自己，效果一般较差，所以我们可以利用多个顶级 AI 之间相互审阅，可以更好地暴露问题，提升方案的质量。
二. 警惕 Agent 的锚定效应
我们向 Agent 抛了一个复杂问题，它返回的第一个回答——功能架构、技术选型——会立刻变成你心中的参考点。后面即使你隐约觉得不太对，心理上也倾向于在原方案上"微调"，而不是推倒重来。
解决思路：
- 让 Agent 给你多个方案，同时输出每个方案的优缺点，甚至让它给你一个评分。这样你就不会过早地锚定在第一个方案上，而是可以更客观地评估每个方案的优劣。
- 在看 Agent 输出之前，先自己想一想。 哪怕只是花两分钟列几个关键决策点，形成你自己的"锚"。这样你看到 Agent 的输出时，心里是有参照系的，不会被它牵着走。
三. 善于苏格拉底式提问
Agent 输出有一个特点：它永远都很自信。不管对错，Agent 说话的语气都很笃定。"我建议使用工厂模式来解决这个问题"、"这个实现是线程安全的"、"这样修改不会影响现有功能"。 解决思路： 对 Agent 的每个关键结论反向追问：
- "这个方案在什么情况下会失败？"
- "你搞的这个改动有没有什么潜在的风险？"
- "有没有你没考虑到的边界情况？"
- "如果数据量增长 10 倍，这个设计还 hold 得住吗？"
这里主要强制 Agent 从另一个角度审视自己的输出。你会发现，同一个 Agent，当你让它"论证这个方案好"的时候，它说得头头是道；当你让它"找这个方案的问题"的时候，它也能找出一堆隐患。
四. 避免 Agent 的过度设计
Agent 天生就有过度设计的毛病。代码生成的边际成本为零，加功能、堆代码量对它来说太容易了。如果经常review AI生成的代码，不难发现：
- 明明一个现成的库几行代码就能搞定的事，它偏要从零造轮子，洋洋洒洒写了几百行同样的逻辑，
- 它在不同地方重复写了好几遍，也不知道抽个公共函数
- 为了一些根本不可能出现的边界情况，写了一大堆防御代码- 一个一次性操作，它也要给你封装成一个工具类，加配置项、加扩展点
解决思路：
在prompt明确约束：
txt请最小化实现，不要过度设计，只做我要求的改动 请直接改动xxx，不要改动其他部分 禁止新增文件,禁止改动xxx模块以外的代码做完一个改动之后，让 Agent 自己清理
txt请你检查一下你的代码，看看有没有重复的逻辑或者过度设计的地方，如果有，请你重构一下，尽量简化实现。 你觉得现在哪些代码是 over-engineering 的？给我清理和优化一下
五. 找到你系统的瓶颈
| 环节 | 有没有可能是瓶颈？ | 怎么判断 |
|---|---|---|
| 任务分解 | 有可能 | 你是不是花大量时间在想怎么拆任务？ |
| Prompt 编写 | 有可能 | 是不是每次都从零开始写 prompt？ |
| Agent 执行 | 一般不是 | Agent 通常秒级/分钟级就完成了 |
| 人类审查 | 最常见 | Agent 的产出是不是在排队等你审查？ |
| 反馈迭代 | 有可能 | 是不是花太多时间在来回修改上？ |
我们整个系统的产出是一个木桶效应，取决于最短的那块木板。我们要找到这个瓶颈，集中精力去优化它。
- 如果瓶颈是任务分解——花大量时间在想怎么拆任务。那就让 Agent 先帮你拆，你来审核和调整，利用 Plan Mode 做这件事
- 如果瓶颈是 prompt 编写——每次都从零开始写 prompt，那就把常用的 prompt 封装成 Skill 或者模板，一次投入，反复使用。
- 如果瓶颈是 Agent 执行，则可以对一些高 TRM 任务采用低参数模型来提高效率。
- 如果瓶颈是人类审查，则可以考虑通过自动化测试减少人工审查的负担（CI/CD、lint、typecheck 这些配一次，永久生效）
- 如果瓶颈是反馈迭代，则提升 prompt 的质量，让 Agent 一次性输出更可靠的代码，减少返工