如何把业务需求拆成 AI 能力

AI 项目最常见的错误，不是技术不会，而是需求一开始就拆错了。一个业务方说“我想做智能助手”，这句话本身几乎没有技术价值。真正有价值的是把它继续拆成：哪里需要模型理解，哪里需要外部知识，哪里需要工具执行，哪里必须由系统兜底。

如果这一步没拆清楚，后面就很容易一股脑上 Agent、上 RAG、上框架，最后看起来技术很多，实际没回答业务问题。

先别问用什么技术，先问这几个问题

一个需求拿到手，先问：

• 用户到底想完成什么目标。
• 这个目标里，哪些内容需要理解自然语言。
• 哪些内容依赖外部知识而不是模型记忆。
• 哪些动作会碰到真实系统、真实权限和真实数据。
• 结果是一次回答就能结束，还是要多步推进。

这几个问题答清楚，技术边界自然会浮出来。

常见能力该怎么对号入座

拆解时可以用很朴素的判断：

• 需要模型理解和生成时，用 LLM。
• 需要外部知识支撑时，用 RAG。
• 需要系统动作时，用 Tool Calling。
• 需要多步推进和动态决策时，再考虑 Agent。
• 需要长期上线时，补 日志、成本、评估、安全。

关键不在于把名词列全，而在于每个名词都只解决它该解决的问题。

哪些需求其实不需要 Agent

这是最值得先泼冷水的地方。很多需求听起来像“智能”，但其实只是：

• 固定流程加一点自然语言入口。
• 文档问答加引用展示。
• 结构化生成加审核。

这些场景通常先用普通 Workflow 或 RAG 就够了。只有当“下一步做什么”本身也需要系统判断时，Agent 才值得被引入。

一个最小拆解例子

以“企业知识库问答”为例，更靠谱的拆法通常是：

• 问题理解：需要模型。
• 文档召回：需要 RAG。
• 结果约束：需要 Prompt 和结构化输出。
• 来源展示：需要引用溯源。
• 权限控制：需要后端。
• 成本与效果跟踪：需要调用日志和评估。

这样一拆，技术主线就会自然落到 LLM + RAG + Prompt + 工程治理，而不是一上来就喊 Agent。

一句话先记住

需求拆解的目标，不是挑技术，而是先把不该交给模型的部分剥出来。

继续阅读

• 01-ai-agent-application-foundation/004-ai-agent-application-capability-levels.md
• 01-ai-agent-application-foundation/005-common-ai-agent-application-scenarios.md
• 06-agent/001-what-is-agent.md