大语言模型（LLM）已经能写代码、写文档、做问题分析，甚至能参与研发流程。但一旦遇到真正的复杂任务——多步骤流程、实时环境变化、带副作用的动作调用——模型常常让人“恨铁不成钢”。
为什么 LLM 在复杂任务上会显得无能为力？从工程与测试视角看，它并不是“不够智能”，而是没有被放进一个具备“执行—反馈—验证”闭环的系统里。
一、LLM 的天赋与天花板
LLM 的核心能力是： 根据历史语料推测最合适的下一段文本。
这带来了强大的生成能力，但同时也天生带了几个限制：
没有真实的因果推理能力它懂“模式”，不懂“原因”。
无法可靠管理长链状态多步骤任务中，关键信息容易丢。
不能直接感知环境变化的数据、实时系统状态它根本看不见。
无法验证自己的输出生成结果是否可执行、是否安全、是否符合业务规则，它无法判断。
幻觉问题不可避免模型会编造 API、参数、事实——而且语气非常自信。
这些限制导致 LLM 很难“独自”完成复杂任务。
二、为什么复杂任务难？因为它是闭环系统，而 LLM 不是
复杂任务通常有三个共同点：
需要明确的行动（Action）例如生成脚本、调用工具、执行操作，不是文本本身。
需要观察反馈（Observation）例如外部系统返回的结果、执行日志、实时状态。
需要基于反馈调整下一步（Correction）这是一种“动态决策”，不是一次生成能搞定的。
LLM 缺少这三种能力，因此它必须依赖额外的系统组件：
LLM（生成） → Agent（执行） → 监控与验证（反馈） → 状态管理（上下文）
mermaid-20251123_024440
三、工程视角下的问题拆解：LLM 为什么掉链子？
- 多步骤任务容易“中途失忆”
例如生成一条复杂的任务链： 数据准备 → API 调用 → 校验 → 清理环境
如果上下文较长，模型很可能忘记前面设定的变量、上下文或约束，导致后续步骤不一致。
- 模型会误用、虚构或拼错工具调用
在某些自动化框架中，模型需要根据 schema 调用工具。 但 LLM 很可能返回一个不存在的字段或参数，导致执行失败。
这种错误不是“工程 bug”，而是语言模型的统计特性决定的。
- 无法处理异常与非理想世界
真实系统里充满“不按剧本走的情况”： 超时、锁冲突、数据缺失、第三方异常……
而 LLM 假设的是“理想路径”。 无法应对异常路径，自然无法完成复杂任务。
- 模型做出的决策不可验证
例如让 LLM 判断： “此操作是否存在高风险副作用？”
它没有足够的世界知识来真正判断风险，最终容易给出错误建议。
- 环境实时变化，模型没有更新机制
库存变化、业务规则调整、权限更新…… 模型不知道，也无法主动感知。
导致“过期的知识”拿来做真实决策。
四、那如何让 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 系统 的工程师。
这正是人工智能测试开发的价值所在。
