Agent 并不存在：从“语言幻觉”到“可执行系统”的一条分界线

我一开始其实是相信 Agent 这套东西的。直觉很简单给模型加上工具 规划它就能像人一样做事甚至你可以轻松构建出一种“错觉”它会分析问题会决定要不要查资料会一步步执行最后给出结果这已经非常接近“智能体”的直觉定义了。但当我真正开始自己实现一套 AgentPlanner / Tool / DAG / Memory之后我逐渐意识到一个更底层的问题我们看到的“决策过程”其实只是语言模型生成的一种解释性结构而不是决策本身。一、一个关键区分生成Generation vs 决策Decision这两件事在直觉上很像但在系统层面完全不同。语言模型在做什么语言模型在做的是给定上下文生成一个概率上最合理的“下一步表达”这就是标准的条件概率建模。它的输出不代表真实状态不保证一致性不包含执行约束决策系统在做什么一个真正的决策系统至少需要状态空间State Space行动空间Action Space转移函数Transition目标函数Objective / Reward这是标准的 Reinforcement Learning里的形式化定义。区别在于LLM 生成的是“看起来像决策的文本”RL/规划系统产生的是“可以执行并改变状态的行为”二、为什么 Agent 会“看起来像真的”因为它刚好卡在一个非常微妙的位置它同时具备“表达能力”和“工具接口”这会导致一种错觉表达 行为举个典型例子我需要先查天气再安排路线这句话有两个层面对人来说这是计划对系统来说这只是字符串关键问题这段话本身不会驱动任何执行真正的执行必须是call(query_weather) → result → feed next step这就是一个很重要的分界线“描述执行” ≠ “执行本身”三、关键转折从“步骤列表”到“计算图DAG”当你开始真正让系统跑起来你会发现任务根本不是线性的例如查天气 ─┐ ├→ 安排行程 → 输出 查景点 ─┘这就是DAGDirected Acyclic Graph这个结构在很多系统里都存在数据处理Spark / Airflow构建系统Bazel容器调度K8s这时 Agent 的本质发生了变化不再是“生成步骤”而是“生成一张可执行的依赖图”四、Agent 的真实系统结构工程视角一旦你接受 DAG 这个模型Agent 可以被严格拆成三层1️⃣ Planner结构生成职责生成节点Task定义依赖关系绑定工具但注意Planner 不执行任何东西它只是“写一张图”2️⃣ Scheduler执行引擎职责拓扑排序Topological Ordering找到 indegree 0 的节点并行执行失败重试 / fallback这实际上是一个分布式任务调度器问题和Apache Airflow或 Kubernetes Job controller 非常类似。3️⃣ Tool原子能力每个节点最终会落到API 调用数据处理或一次模型推理所以更精确的定义是Agent 结构生成器 执行调度器 外部能力接口五、PLAN / TOOL / CHAT本质是执行拓扑选择很多系统把这一步叫“意图识别”但这是一个误导。你真正要解决的是系统接下来进入哪一种执行模式这三种模式其实对应三种“计算路径”CHAT纯生成LLM → 输出TOOL单步执行LLM → tool_call → tool_result → LLMPLAN多步调度LLM → DAG → Scheduler → 多节点执行这在系统层面更像一个 runtime router而不是 classifier六、为什么必须引入 needAction控制信号语言模型有一个默认行为永远倾向于“生成回答”但在 Agent 系统中你需要区分表达response行为action这就是 needAction 的作用[needAction:true]它不是 hack而是一个协议层Protocol Layer它解决三个核心问题1. 控制执行边界避免模型“误触发”执行流程2. 解耦表达与行为让系统可以先判断再执行3. 提供调度入口成为 Router 的触发条件如果用系统类比它类似于操作系统中的“中断信号Interrupt”七、为什么现在的 Agent 不是真正的 Agent从控制论角度看一个真正的 Agent应该具备状态更新能力可验证决策路径多路径评估policy evaluation反馈闭环feedback loop而当前的大多数 Agent没有真实状态只有上下文没有策略比较没有长期反馈优化所以更准确的说法是当前 Agent Prompt Tool Control Flow而不是Autonomous Intelligent Agent八、一个更严谨的定义如果要用工程语言定义Agent 是一个“基于语言模型的可编排执行系统LLM-Orchestrated Execution System”它的核心能力不是智能理解而是编排Orchestration调度Scheduling执行Execution九、设计方向的变化非常关键一旦你接受这个结论你的系统设计会彻底改变你不再优化prompt 写得更像人输出更自然解释更合理而是开始优化✅ 可执行性Executabilityplan 能不能跑✅ 可控性Controllability是否可以强制路径✅ 可观测性Observability是否能 debug✅ 可恢复性Recoverability失败之后怎么办这些是典型的分布式系统问题结尾如果你现在在做 Agent可以问自己一个问题你是在构建一个“会思考的系统”还是在构建一个“可以稳定执行的系统”前者是幻觉后者是工程而真正的分界线不在模型能力而在你有没有把它当成一个系统来设计你有没有把 Agent 当成一个系统来设计很多人做 Agent其实不是在做系统。是在用 prompt 拼一个“看起来能工作的东西”一开始你可能感觉不出来差别。因为demo 能跑case 能过甚至效果还不错但一旦你开始做复杂一点的东西你会遇到一组非常典型的问题为什么同一个输入有时候走 TOOL有时候直接回答为什么 plan 有时候能跑有时候直接崩为什么一旦失败整个流程就断掉了为什么你根本不知道它刚刚“在想什么”这些问题有一个共同点它们不是“模型问题”而是“系统缺失”一、一个关键分界线你到底在做什么你可以用一句话判断自己在哪个阶段❌ Prompt 工程阶段你在做的是调 prompt调 temperature改 few-shot让模型“更听话”本质是在优化一个函数的输出分布✅ 系统设计阶段你在做的是切分模块Planner / Router / Scheduler定义协议needAction / JSON schema控制执行路径管理状态与失败本质是在构建一个运行时系统runtime system这是两个完全不同的问题空间。二、为什么“不是系统”会出问题如果你没有系统边界你的 Agent 会变成一个“无限膨胀的 prompt”你会不断往里面加规则如果用户问天气 → 调工具 如果用户问复杂问题 → 先规划 如果……最后变成一个不可维护的条件集合这在软件工程里其实就是没有架构的 if-else 地狱三、系统设计的最小闭环如果你真的把 Agent 当系统你至少需要这四个层1️⃣ 输入层Input Layer负责用户请求标准化上下文管理memory / history2️⃣ 决策层Routing Layer核心问题下一步走哪条路径这就是PLAN / TOOL / CHAT或更细粒度的 runtime routing3️⃣ 执行层Execution Layer包括Tool 执行DAG 调度并行 / 重试 / fallback4️⃣ 状态层State Layer这是很多人完全没做的一层当前执行到哪一步每个节点的结果错误信息是否需要恢复如果缺了这一层你的系统就没有“连续性”四、真正的难点状态而不是生成大多数人以为难点在“让模型输出一个好 plan”但实际难点在让这个 plan 在真实环境里跑完这就会涉及状态持久化中断恢复并发冲突结果依赖这些问题本质上已经变成分布式系统问题你会开始遇到类似问题一个 step 执行慢是否阻塞整个 DAGtool 返回异常是否重试怎么重试plan 中某个依赖错误是否重规划这些问题和 LLM几乎没关系五、为什么大多数 Agent 很“脆”因为它们只有生成能力generation而没有控制能力control在系统设计里这两者是完全不同的层generation → 内容control → 行为你现在的大多数 Agent其实是用 generation 去模拟 control这就是为什么它看起来很聪明但一旦复杂就崩六、一个更底层的理解Agent ≈ 解释器Interpreter如果你换个角度看Planner 输出 → 类似“代码”Scheduler → 类似“执行引擎”那整个 Agent 更像一个“动态解释执行系统”类似于工作流引擎脚本执行器或轻量编排系统而 LLM 的角色是生成“待执行程序”这个视角一旦成立很多问题会变得非常清晰为什么需要 schema类型约束为什么需要 needAction控制信号为什么需要 DAG执行结构因为你本质在做的是让模型写程序然后由系统执行程序七、设计的转折点当你意识到这一点你的设计会发生一个明显变化你不再问“这个 prompt 能不能更聪明”而是开始问这个模块边界清不清晰数据流是不是明确状态是不是可恢复执行是不是可观测这就是从Prompt 工程 → 系统工程八、一个简单但致命的问题你可以用这个问题测试你的 Agent如果现在中途断电它能不能恢复如果答案是❌ 不行只能重来那说明你还没有系统只有一次性流程九、结论Agent 的真正难点不在模型不在 prompt而在你有没有构建一个可以运行、可以控制、可以恢复的系统你可以做一个“看起来会思考的东西”也可以做一个“真的能把事情做完的系统”这两者之间的差距不是模型能力而是你有没有跨过那条系统设计的分界线