模型并非产品。真正的产品在于此。
我把时间花在构建 AI 以及与交付 AI 的工程师交流上。在演示（demo）与真正的生产系统之间存在着鸿沟。许多人对此并不坦诚。
每个人都把一切都称为“智能体”（agent）。一个带有循环的脚本是智能体。一个带有记忆的聊天机器人也是智能体。这会导致工程上的错误：你会对简单的任务过度设计，而对复杂的任务设计不足。
智能体需要一个目标。它不仅仅是遵循指令。智能体会决定下一步该做什么。它能处理失败。它知道何时任务完成。
- 如果人类告诉你的系统每一步该怎么做，那它只是一个聊天界面。
- 如果你的系统能从失败的工具调用中恢复，你才是在构建智能体。
- 如果你的系统能将目标分解为子任务，那它才是真正的智能体。
真正的智能体部署通常是垂直细分的。它们专注于做好一件事，例如文档提取或代码审查。成功的团队不会盲目追求新模型，而是专注于以下三个领域：
- 工具设计：接口是否简洁？
- 错误处理：当工具返回空结果时会发生什么？
- 可观测性：你是否可以追踪智能体做出决策的原因？
像 LangChain 或 CrewAI 这样的框架，其重要性远不如设计模式。框架只是脚手架，架构才是建筑本身。
使用这些模式：
- 先规划后执行。使用一个步骤进行规划，使用另一个独立的步骤进行执行。
- 将检索与推理分离。获取上下文和使用上下文是两项不同的工作。
- 明确的任务移交。当一个智能体将工作传递给另一个智能体时，要结构化地处理移交过程。
RAG 已成为标准，但分块（chunking）往往做得不对。如果你对文档的分块处理不当，模型就会丢失上下文并产生幻觉。如果你的 RAG 结果毫无用处，请修复你的分块和元数据，不要责怪嵌入模型（embedding model）。
模型会变得越来越好。上下文窗口会不断扩大。成本会降低。但这并不会改变工程上的挑战。你必须构建出那些在你不在场时也能让你放心的系统。
专注于治理、可观测性和工具使用。真正重要的工程师将是那些精通系统设计，而不仅仅是提示工程（prompt engineering）的人。
Source: https://dev.to/aibughunter/the-model-is-not-the-product-heres-what-actually-is-52b5