大语言模型（LLM）已经能写代码、写文档、做问题分析，甚至能参与研发流程。但一旦遇到真正的复杂任务——多步骤流程、实时环境变化、带副作用的动作调用——模型常常让人“恨铁不成钢”。
为什么 LLM 在复杂任务上会显得无能为力？从工程与测试视角看，它并不是“不够智能”，而是没有被放进一个具备“执行—反馈—验证”闭环的系统里。
一、LLM 的天赋与天花板
LLM 的核心能力是： 根据历史语料推测最合适的下一段文本。
这带来了强大的生成能力，但同时也天生带了几个限制：
- 没有真实的因果推理能力它懂“模式”，不懂“原因”。
- 无法可靠管理长链状态多步骤任务中，关键信息容易丢。
- 不能直接感知环境变化的数据、实时系统状态它根本看不见。
- 无法验证自己的输出生成结果是否可执行、是否安全、是否符合业务规则，它无法判断。
- 幻觉问题不可避免模型会编造 API、参数、事实——而且语气非常自信。
这些限制导致 LLM 很难“独自”完成复杂任务。
二、为什么复杂任务难？因为它是闭环系统，而 LLM 不是
复杂任务通常有三个共同点：
1. 需要明确的行动（Action）例如生成脚本、调用工具、执行操作，不是文本本身。
2. 需要观察反馈（Observation）例如外部系统返回的结果、执行日志、实时状态。
3. 需要基于反馈调整下一步（Correction）这是一种“动态决策”，不是一次生成能搞定的。
LLM 缺少这三种能力，因此它必须依赖额外的系统组件：
LLM（生成） → Agent（执行） → 监控与验证（反馈） → 状态管理（上下文）
三、工程视角下的问题拆解：LLM 为什么掉链子？
1. 多步骤任务容易“中途失忆”
例如生成一条复杂的任务链： 数据准备 → API 调用 → 校验 → 清理环境
如果上下文较长，模型很可能忘记前面设定的变量、上下文或约束，导致后续步骤不一致。
2. 模型会误用、虚构或拼错工具调用
在某些自动化框架中，模型需要根据 schema 调用工具。 但 LLM 很可能返回一个不存在的字段或参数，导致执行失败。
这种错误不是“工程 bug”，而是语言模型的统计特性决定的。
3. 无法处理异常与非理想世界
真实系统里充满“不按剧本走的情况”： 超时、锁冲突、数据缺失、第三方异常……
而 LLM 假设的是“理想路径”。 无法应对异常路径，自然无法完成复杂任务。
4. 模型做出的决策不可验证
例如让 LLM 判断： “此操作是否存在高风险副作用？”
它没有足够的世界知识来真正判断风险，最终容易给出错误建议。
5. 环境实时变化，模型没有更新机制
库存变化、业务规则调整、权限更新…… 模型不知道，也无法主动感知。
导致“过期的知识”拿来做真实决策。
四、那如何让 LLM 真正“能干活”？核心在于系统化
企业要让 AI 执行复杂任务，必须构建一套闭环系统，而不是把希望寄托给模型本身。
业内成熟的做法通常是“四层结构”：
1）语言层（LLM）
负责理解任务、生成计划、拆解步骤。
2）工具执行层（Agent Engine）
负责调用工具、执行 API、处理参数、捕获异常。
3）状态层（State Store）
记录执行进度、快照、变量、回滚点，避免“中途失忆”。
4）验证与监控层（Safety & Monitor）
负责校验动作是否安全、结果是否正确，并提供可观察性。
这套结构才是复杂任务成功的关键。
五、必须重点验证什么？
A. 状态一致性
任务执行前后是否满足预期，变量是否遗漏或错乱。
B. 工具调用正确性
- API 名称是否正确
- 参数格式是否符合 schema
- 返回值是否被正确解析
C. 异常场景与重试策略
包括：
- 超时
- 空返回
- 第三方异常
- 多次失败后的回滚机制
D. 行为安全性
对任何可能带副作用的操作（删库、修改状态），必须进行规则拦截与人工复核。
六、真正决定成败的不是模型，而是“能否验证模型”
LLM 不是复杂任务失败的原因，“无验证的 LLM”才是。复杂任务的本质就是： 任务 = 决策 + 执行 + 状态管理 + 反馈校验 + 安全机制
模型只负责其中的 “决策生成”。 剩下的部分全靠系统设计与测试工程来兜底。
七、不要迷信 LLM 的天赋，要建设它的“基础设施”
越是复杂的任务，越依赖：
- 清晰的任务拆解
- 安全可控的工具调用
- 完整的异常处理
- 强韧的状态管理
- 自动化可验证的测试体系
未来真正有价值的岗位不是“Prompt 工程师”， 而是能设计、验证、监控、治理 AI 系统 的工程师。
这正是人工智能测试开发的价值所在。
