不知道各位有没有跟我一样的感觉：在阅读资料时，假若旁边有人和我一起讨论，那阅读效率会大大提高。而今，在这个 LLM App 已不是稀罕物的时代，我们可以跟 AI 跟一起讨论以避免找人的麻烦。或者更进一步，让 AI 相互讨论，我们只需在一旁观察它们的结果就好。
这样，一来可以节约时间和精力（因为你可以在它们讨论时干其他的事情，这是不是有点像带领一支研究团队了 😄）；二来可以借助 AI 丰富的预训练成果提出更好的问题，避免无法讨论的尴尬。
懂行的读者可能会说：等等，你说的可是 Agent Swarming / Orchestration ？
的确，有点相关。但对于咱们的场景，没必要说的那么高大上。成天拽新词不是咱的风格，我就喜欢把复杂事情说得下里巴人（这才是真懂嘛）。当然，如果想找老板收钱，确实要阳春白雪，哈哈。
闲话少说，说回正题。
让 AI 就一个主题讨论其实很简单，观察真实的讨论场景，它不过就三部分：
- 主题
- 问者，提出问题
- 答者，回答问题
其中，主题内容和答者都不用过多说明。问者则需稍加说明：
- 不会重复提问。
- 除了会依据主题内容提问，他/她还会根据答者的回答进行追问。
这两点都指向一个暗示：记忆。
说完背景，让我们来看看如何让 AI 左右互搏。
前文（《打造一支个人专属的 AI 写作团队》，新进来的看文末）说过 llm 编程无非就是：
- 文本输入（这里不讨论多模态输入，故简化一下），文本输出。
- 输入方一般是人类用户，输出方一般是 LLM。
要 AI 互相讨论，无非就是让 AI 替代人类用户。同时，考虑到人类的记忆，无非就是将一方（答者）的输出（累计）作为输入传递给另一方（问者）。
于是乎，最终的设计如下：
- 对话双方：问者和答者。
- 问者：
- 输入: 主题内容 + 历史回答 + 历史问题
- 输出: 问题
- 答者：
- 输入：主题内容 + 问题
- 输出：回答
在提问方记录历史的作用就是模拟人类记忆，避免重复。
代码实现可在：https://github.com/DTeam-Top/tsw-cli/blob/main/agent/think.py 中找到，有兴趣可以自取，但了解思路之后，自行实现也非难事。
关于代码的若干说明：
- 它实现了若干提问的模式，目前就是：批判性思维和 FAQ。
- agno 中虽然有 memory，但我没有使用，觉得自己控制更精准，而且我的实现是 CLI 方式，所以也不需要。
- 这里有讨论轮次的限制，一来是避免无限循环，二来是避免 token 超标。
- 这里有返回字数的限制，避免 token 超标。
- 这里的提问和回答都是一次一批，即批处理模式，这是为了节约时间，各位可以根据自己的场景自行实现。比如，我的另一个 tsw 插件中就是一问一答的模式，用户可在 ui 上观察到 ai 相互进行讨论的过程。
- 由于是批量问答模式，所以最后成文时有一个重新排版的过程，改善阅读体验。
另：关于 agent 的协作是个大话题，未来会有专题系列。
经过前后两篇文章的介绍，某些敏锐的读者应该会觉察到面向 llm 编程与常规编程的些许差异了吧，哈哈？
附：FAQ 示例
Tips for building AI agents：https://www.youtube.com/watch?v=LP5OCa20Zpg
1. 什么是工作流(workflow)，它与 Agent 的区别是什么？
工作流是预先编排好的 LLM 调用链，步骤固定。Agent 则更自主，LLM 决定运行次数直到找到解决方案。
2. 文中所述的 “多智能体环境 (multi-agent environment)” 指的是什么？
多智能体环境指多个 Agent 相互协作的环境，例如文中让多个 Claude 玩“狼人杀”游戏。
3. 在编码 Agent 中，提高 Agent 性能的最大障碍是什么？
目前提高编码 Agent 性能的最大障碍是验证问题，即如何为 Agent 提供有效的反馈。
4. 文中所说的“Werewolf”游戏是什么？
“狼人杀”是一个社交推理游戏，玩家通过交流和推理来判断彼此的角色。
5. 针对开发者，在构建 Agent 时，有哪些建议？
- 确保有方法衡量结果。
- 尽可能从简单开始，逐步增加复杂性。
- 构建能随着模型能力提升而改进的产品。
6. 构建消费者 Agent 有哪些过度炒作的方面？
消费者代理被过度炒作，因为指定偏好和验证结果的工作量几乎与自己完成一样大，且风险高。
7. 文中提到的”agentic search”是什么？
“Agentic search” 是一种利用代理进行深入、迭代搜索的方法，可以在一定程度上牺牲精度以换取更全面的信息。
8. Barry 在构建 Agent 时遇到的有趣经历是什么？
Barry 的经历是，他和另一位工程师通过模拟 Claude 的思考方式来理解模型决策，从而更好地设计 Agent。
9. 模型不具备哪些知识，需要在 prompt 中明确？
模型可能不具备很多上下文和知识，需要在 prompt、工具描述和环境中明确。
10. 文中提到的 SWE-bench 是什么？
SWE-bench 是用于评估代码生成能力的基准测试。
11. Anthropic 公司在文中对 Agent 的定义是什么？
Agent 是让 LLM 决定运行多少次，持续循环直到找到解决方案。
12. 为什么现在是发布关于构建有效代理的文章的好时机？
现在模型有能力执行许多 agentic 工作流程，为了更容易地进行对话。
13. 在实际代码中，Agent prompt 和 workflow prompt 有什么区别？
Agent prompt 更开放，提供模型工具进行检查，而 workflow prompt 是直线型的固定步骤。
14. 文中提到，与单 LLM 相比，多 LLM 有什么优势？
从单个 LLM 发展到 LLMs 协调自身。
15. 在哪些情况下，使用 simpler systems 会比 agents 更有效？
当问题可以使用更简单的系统解决时，不应过度使用 agents。
16. 构建有效的 Agent 的关键要素是什么？
关键要素：模型具备自主决策能力，能根据环境反馈迭代优化，直至达成目标。
17. 除了编码和搜索之外，agent 在哪些任务上非常有用？
虽然文章提到了编码和搜索，但并未明确提及其他 agent 非常有用的任务。
18. 企业在 2025 年采用 Agent 的最大潜在好处是什么？
企业采用 agent 可自动化重复性任务，显著降低成本，从而扩大业务规模。
19. 除了代码测试，还有什么验证方法可以提高 Agent 性能？
代码测试外，还需找到能验证和添加测试的方法，以便模型在返回结果前自我验证。
20. 文章中提到的 Sonnet v2 refresh 对 Agent 有何影响？
Sonnet v2 refresh 后，作者用 agent 跑 OSWorld，通过模拟 agent 视角来优化设计。
21. 目前在生产环境中，Agent 有哪些被低估的潜力？
节省少量时间，规模化后意义重大。
22. 验证在 agent 性能中起到的作用是什么？
代码 agent 中，验证代码的测试结果能为模型提供反馈，使其收敛到正确答案。
23. 在哪些情况下不适合使用 Agent？
消费者任务，指定偏好设置与亲自操作工作量相近，且验证成本高、风险大。
24. 构建工具时，开发者常犯的错误是什么？
工具极简，缺乏文档和清晰的参数命名，导致模型难以有效利用。
25. Agent 的未来发展方向是什么？
多智能体环境，业务采用 agent 自动化重复性任务，规模化扩展。