从LLM Call到Dynamic Workflow，AI系统中自主性与确定性的权衡
AI应用技术名词和热点迭代很快，当发展到SKILL阶段后，也会讨论：下一个技术会是什么呢？
从最早的LLM Call 如Chat Completion，到引入提示词工程来引导模型输出、降低幻觉，接着是应用Workflow来提升确定性。
随着模型能力大幅提升，尤其是对提示词的遵循度，Agent自主性和确定性也快速取得了使用者的信任，让AI应用迅速步入了Agent时代，开始围绕着Agent去权衡自主性和确定性。
| 阶段 | 核心做法 | 自主性 | 确定性 |
|---|---|---|---|
| LLM Call | 直接调用大模型的chat/completion接口，把用户输入交给模型生成回复。 | 自主性最高。模型直接理解问题并生成答案，适合快速验证问答、总结、翻译、改写、代码生成等能力。 | 确定性最低。系统只能控制API封装、参数、超时和错误处理，回答内容基本由模型决定，复杂任务里的错误往往到最终答案才暴露。 |
| Prompt Engineering | 通过角色、目标、格式、示例、反例、XML标签等方式，把任务要求写进提示词。 | 自主性仍然很高。模型可以在语言约束内发挥，但语气、结构、边界和验收口径变得更清楚。 | 确定性前移到"语言契约"。它能提升一致性，但提示词仍是软约束，不能可靠承担权限、金额、状态迁移等高风险逻辑。 |
| Context Engineering | 动态组织模型可见的信息：系统指令、历史对话、RAG结果、文件、工具定义、工具返回和记忆。 | 自主性被放在更好的材料里。模型仍然负责推理和生成，但它看到的是经过筛选、召回、压缩和组织后的上下文。 | 确定性扩展到检索、排序、压缩、去重、来源标注和上下文装配。风险变成召回错漏、旧信息、噪音、成本和延迟。 |
| Harness Engineering | 在模型外侧建设控制平面：agent loop、工具路由、权限、审批、沙箱、追踪、恢复、评估和运行状态。 | 自主性上移到计划、选择和调度。模型可以做长程任务，但行动会经过工具契约、权限、审批、沙箱和校验。 | 确定性落到执行环境、工具契约、权限审批、校验、审计、追踪和恢复机制。代价是工程复杂度上升，过度约束会削弱灵活性。 |
SKILL方案是Agent时代被广泛采纳的一种权衡方案，通过SKILL.md和渐进式加载来平衡上下文、流程确定性和AI自主性，并将高确定性事项固化成scripts，兼具降低功效。
最近Anthropic推出了Dynamic Workflows，进一步验证了AI应用的一条发展主线：
把哪些环节交给AI自主发挥，把哪些环节用代码保证确定性？
这个问题目前还是实践出真知，没有银弹，需要结合具体业务场景来实施。毕竟从一开始Agent刚风行的时候，OpenAI的Agent官方指南就指出：不是所有事情都要Agent化。
自主性，是把事情交给模型，让它理解、推理、计划、调用工具。
确定性，是把关键步骤重新固化成代码、流程、校验和脚本，尽量让系统稳定、可复现、可交付。
从直接调用模型开始
最早的AI应用很直接：通过LLM Call调用大模型的chat/completion接口，把用户输入交给模型，让模型返回结果。
这个阶段的特点是简单，也足够惊艳。一个接口，一段文本，就能完成问答、翻译、总结、改写，甚至生成一段可运行的代码。
但问题也很快出现。模型很强，却不稳定。同一个问题，换个说法，答案可能变了；上下文稍微复杂一点，结果也会漂移。它可以自由发挥，但很难天然满足工程系统对稳定性的要求。
Prompt Engineering：用语言给自主性加边界
Prompt Engineering本质上是用结构化的自然语言描述给模型划范围。
告诉它角色、目标、输出格式、限制条件、示例和反例。我们希望模型仍然保持理解和生成能力，但不要散开太远。
这一步很重要，因为它让AI应用从"能聊"走向"能用"。很多时候，一个清楚的提示词就能让结果变得明显可靠。
但提示词仍然是软约束。它靠语言表达规则，也靠模型理解规则。对于不允许出错的环节，比如金额计算、权限判断、数据写入、状态迁移，只靠提示词就不够了。
Workflow：把可确定的部分铺成轨道
对于不允许出错的场景，就不能只靠自然语言炼丹，让模型自由发挥。当任务变长，只靠一次模型调用也不够。
于是Workflow出现：先分析需求、预处理，再检索资料、组织提示词，接着调用模型进行处理，最后在后置环节做校验和输出。一个任务被拆成多个节点，经典的输入、处理、输出。
Workflow把系统的一部分确定下来。模型不再完全自由游走，而是在轨道上完成局部判断。
这很像传统软件工程回到了AI系统里。状态、分支、重试、异常处理、验收标准，这些原来就重要的东西，在AI应用里变得更重要。
因为AI越能做事，工程系统就越需要知道它做到了哪一步，失败在哪里，能不能重试，重试会不会造成副作用。
Context Engineering：控制模型看见什么
随着模型变得更强，上下文窗口变大，提示词遵循度变更，就从Prompt Engineering进入到Context Engineering。
如果说Prompt是在告诉模型"你应该怎么做"，Context Engineering就是在控制模型"你基于什么来做"。
知识库、历史对话、用户偏好、项目文件、工具返回、运行日志，这些都会进入上下文。模型的能力不只取决于它本身，也取决于它当下看到的材料。
这一阶段的重点，从写一句好提示词，变成了组织信息。什么内容需要召回，什么内容应该丢弃，什么内容必须保持最新，什么内容只在特定任务里出现。
上下文越丰富，AI越像一个真正参与工作的系统；但上下文越丰富，也越容易混入噪音。它会带来更强的自主性，也带来更多不确定性。
所以工程上又会自然往回收：检索要有规则，记忆要有更新策略，工具结果要有结构化字段，关键上下文要有来源和时间。
Harness Engineering：收口所有Agent外围工程
不管是提示词工程，还是上下文工程，都算是AI驾驭工程/AI控制工程，Multi-Agent、Skill、Context、Workflow等各种手段都是按需结合。
Skill：把经验沉淀成可调用能力，把流程变成自然语言描述
Skill是Harness时代的主要方案。
一开始，一个Skill可能只是一个SKILL.md：里面写着某类任务的背景、步骤、注意事项和输出要求。它像一份给AI看的操作手册。
但只写手册还不够。很多重复、精确、容易出错的部分，会慢慢从自然语言里分离出来，变成Script脚本。
比如解析文件、校验格式、批量改名、渲染预览、跑测试、检查链接。这些事情让AI每次凭感觉做，成本高，也不稳定。写成脚本之后，确定性就回来了。
这一步很有意思。表面上看，我们在增强AI能力；实际上，我们也在把AI不擅长稳定完成的部分交还给代码。
Skill不是纯粹扩大自主性，而是在重新分工：AI负责理解意图、选择路径、连接上下文；代码负责执行那些可以被明确描述、可以被验证、可以被重复运行的动作。
Dynamic Workflow：把自然语言变成代码流程
过去Workflow更像是人提前写好的流程图。现在，AI系统开始尝试根据任务动态选择Skill、组织步骤、生成临时流程，再在流程中调用模型、工具和脚本。
它固定的不只是整条流程，而是每个可验证的节点、工具契约、输入输出格式和失败处理。变化的是节点之间如何组合，以及在某个具体任务里先做什么、后做什么。
我觉得，Dynamic Workflow是AI自主性进一步提升，开始进入到用自主性来提升确定性的下一层。
AI不只是生成答案，也开始生成做事路径；但每条路径落到具体执行时，仍然需要代码、工具、脚本和校验来兜住。
一条线，两个方向
回头看这条线，可以大致这样理解：
- LLM Call：通过chat/completion接口把问题直接交给模型，获得最大自由度。
- Prompt Engineering：用语言约束模型，让输出更接近目标。
- Context Engineering：组织上下文，让模型基于正确材料工作。
- Workflow：把长任务拆成流程，让关键步骤可追踪。
- Skill：把经验沉淀成可复用能力，把重复动作脚本化。
- Dynamic Workflow：让流程组合也具备一定自主性，但保留节点级确定性。
如果换成四阶段口径，Workflow、Skill、Dynamic Workflow都可以理解为Harness Engineering继续展开后的不同粒度。名字可以变化，但底层问题没有变化：我们不断把AI系统里"模糊但有价值"的部分交给模型，把"明确且高风险"的部分交给代码。