Agent、工作流、Skill、上下文窗口——这些词在会议和文章里高频出现，但十个人里有八个的用法互相矛盾。概念不清的代价是真实的：采购时被"智能体"话术带偏，架构评审时对"要不要上 Agent"吵不出结果。这篇把几个核心概念辨析清楚，重点讲它们之间的边界关系。
从 LLM 说起：能力与局限
大语言模型是一切概念的地基。它本质上在海量文本上学会了"预测下一个词"，由此涌现出问答、写代码、翻译等能力。三个关键属性决定用法：
- Token：计费与计量的最小单位，约 1-2 个汉字一个 Token，成本估算都从这里起算。
- 上下文窗口：一次能处理的文本上限。大窗口不等于免费——超出窗口的内容等于不存在，这是长对话"失忆"的根源。
- 幻觉：模型不会承认"不知道"，缺信息时会编造听起来合理的答案。专业场景的输出必须有人工或程序校验，这不是可选项。
工作流与 Agent：一条清晰的分界线
这两个概念最容易混，用一句话切开：工作流是人定好步骤，AI 在固定环节参与；Agent 是 AI 自己决定下一步做什么。
工作流确定性强：审批链路、内容审核管道、固定格式的报表生成，每一步做什么都事先写死，AI 只是在某些节点做分类或生成。可控、可审计、出错范围有限。
Agent 把决策权交给模型：给它目标和工具，它自己规划路径、调用工具、根据结果调整。灵活但不可预测——同样的问题跑两次可能走不同的路，成本和时间都难预估。
选型判断只有一条：流程能不能提前画出来。能画出来就工作流，画不出来才考虑 Agent。把本该是工作流的业务硬做成 Agent，等于把确定性换成了不确定性，还多付了 token 费。
Skill：能力的封装单位
Skill 是把"一类任务的完整做法"打包成的可复用模块——包含提示词、参考资料、执行流程。它解决的问题是"每次都从头教模型"的低效：写好一次，所有会话都能调用。
Skill 与 Agent 的关系是包含而非并列：Agent 可以按需加载不同 Skill 来扩展能力面。一个实际判断标准——如果某个提示词你在三个不同会话里重复写过，它就该被抽成 Skill 了。
MVP：验证逻辑而不是炫技
AI 产品的 MVP 版本，核心是验证"这个问题是否值得用 AI 解"，而不是把功能堆全。常见误区是 MVP 阶段就上多 Agent 协作、复杂工具链——验证阶段用最简单的单次调用 + 人工兜底就够了。先用最小方案测真实需求强度，需求坐实了再上重架构，顺序反了就是在给没人用的功能做优化。
概念地图与使用建议
把关系串起来：LLM 是引擎，Prompt 是每次的驾驶指令，Skill 是预制好的驾驶手册，工作流是固定路线，Agent 是把方向盘交给 AI。日常应用按这个顺序评估成本：单次调用最便宜，工作流次之，Agent 最贵且最难测。团队引入 Agent 前先问：这个任务的容错率撑得起模型自主决策的不可预测性吗？答案是否的话，工作流加 Skill 的组合通常是更稳的答案。
评论0