我们真的需要 agent 吗？
我们需要 agent，只是我们可以先不用 agent
最近一直在思考一个问题：构建基于大型语言模型（LLM）的应用时，我们真的需要 Agent 吗？过去一年，我们见证了各行各业 LLM Agent 的兴起。但有趣的是，最成功的案例往往并没有使用复杂的框架或专用库。他们只是采用了简单、可组合的模式。
这就像烹饪一样。你不需要一堆花哨的厨具就能做出一顿美味的佳肴。有时候，最简单的食材和方法反而能带来最好的效果。
那么，Agent 到底是什么？
有人将其定义为可以独立运行的自主系统，利用各种工具完成复杂任务。
也有人认为它只是遵循预定义工作流程的更规范的实现。
我也一直在探索一个问题，什么时候应该使用 Agent，什么时候不应该呢？
目前的收获是：从最简单的方案开始。只在必要时才增加复杂性。
很多时候，优化单个 LLM 调用，配合检索和上下文示例就足够了。
Agent 通常会牺牲延迟和成本以换取更好的任务性能。
我们需要权衡这种取舍是否值得。
如果确实需要更复杂的系统，那么对于明确定义的任务，workflow 提供了可预测性和一致性；而当需要灵活性和模型驱动的决策时，Agent 则是更好的选择。
我们可以从直接使用 LLM API 开始。很多时候只需几行代码即可实现我们需要的功能。
生产环境中的 Agent system 通常遵循一些共同的模式。
它们都建立在一个基础之上：增强的 LLM。它通过检索、工具和记忆等功能进行增强。
我们可以将这些模式视为乐高积木，从简单的提示链到自主 Agent，逐步增加复杂性。
Agent 代表着 LLM 应用的未来。随着 LLM 在理解复杂输入、推理和规划、可靠地使用工具以及从错误中恢复等关键能力方面的成熟，Agent 正在生产环境中崭露头角。Agent 可以处理复杂的任务，但它们的实现通常很简单。它们通常只是在循环中根据环境反馈使用工具的 LLM。因此，清晰周密地设计工具集及其文档至关重要。
何时使用 Agent？
当问题是开放式的，难以或不可能预测所需的步骤数，并且无法硬编码固定路径时，就可以使用 Agent。Agent 的自主性使其非常适合在受信任的环境中扩展任务。
但 Agent 的自主性也意味着更高的成本和潜在的复合错误。
所以最好还是先在沙盒环境中进行广泛的测试，并设置适当的防护措施。
在 LLM 领域，成功不在于构建最复杂的系统，而在于构建满足你需求的正确系统。从简单的 prompt 开始，通过全面的评估进行优化，并且仅当简单的解决方案不足时才添加多步骤 agent。
在实现 Agent 时，我们尝试遵循三个核心原则：
- 保持 Agent 设计的简洁性。
- 通过明确显示 Agent 的规划步骤来优先考虑透明度。
- 通过全面的工具文档和测试来精心设计ACI。
框架可以帮助我们快速入门，但当一切转向生产环境时，请不要犹豫，减少抽象层并使用基本组件进行构建。
通过遵循这些原则，我们可以创建不仅强大，而且可靠、可维护且受用户信任的 Agent。