我想要构建什么样的Agent？

如果要问Agent和其他过往的软件相比最大的差异来哪里，最直观的答案几乎总是模型。

随着模型有更强的语言理解、更长的上下文、更好的工具调用和更强的推理能力，Agent从一个简单的“对话模型外加几个函数”，逐渐变成了真正能够完成复杂任务的系统。

这也形成了一种非常自然的工程直觉：模型越强，就应该把更多事情交给模型。

过去很多Agent的演进，本质上也确实遵循着这样的方向。

最开始，我们只让模型回答问题，后来开始让模型选择工具，再后来，让模型自己规划任务、决定执行顺序、修改文件、检查结果、遇到失败后重新尝试，甚至判断任务是否已经完成。

Agent越来越“自主”，Agentic的思想也从中诞生了：让模型拥有更多决策权。

我并不认为这套逻辑本身有什么明显的问题。

甚至很长一段时间里，我也认为下一代 Agent 大概只是在等待更强的模型——更好的 reasoning、更长的 context、更稳定的 tool use。只要底层模型继续进步，Agent 自然就会跟着变得更可靠。

但人嘛，总是不甘心自己什么都不做的，我虽然不想否定这个结论在一定程度上的正确性，但是我还是会提出一些怀疑。

这种怀疑最初并不是来自技术问题的考虑，而是来自一些非常细小的使用体验。

从2025年9月第一次使用Agent——Claude code，到现在2026年9月在使用各种如雨后春笋般涌现的相当成熟的 Coding Agent ，我能够非常明显地感受到模型能力带来的变化。它们已经可以阅读陌生项目、理解代码关系、跨文件修改、调用命令、运行测试，甚至持续完成过去需要人手动处理的大量工作。

但与此同时，我也越来越频繁地碰到另外一种问题：模型的不确定性，开始让我厌烦。

曾经有人和我提过一个观点：我们和一个新模型的蜜月期，持续到我们第一次误以为“它已经了解我”为止。在此之后就会因为我们和它的上下文不对称的原因出现分歧。

我想要说的是，这种现象并不总是表现为明显的幻觉。

更多时候，其实只是模型理解偏了一点、多修改了一点、对当前文件状态做了一个错误假设。

这些误差往往都会被归结到模型的能力问题上，而不是真正的Agent能力问题，所以Agent的构建者们或许总是容易忽略它。

但这件事真的和Agent无关吗？

我在构建 Open Codesign 这个开源项目时，曾经反复产生一个非常简单的问题：

如果我只是想修改页面中的一小段文字，或者把某个组件的颜色从 A 改成 B，为什么这件事情仍然必须通过和 Agent 对话来完成？

我需要先用自然语言描述需求。

模型理解我要修改什么，找到对应文件，判断应该改哪里，再生成一次代码。

然后我还需要重新检查：它有没有改错位置？有没有顺手修改其他内容？有没有因为理解偏差产生额外变化？

可如果系统已经知道：

目标组件 = Button
目标属性 = color
旧值 = blue
新值 = green

那后面的修改其实已经几乎不存在“智能问题”。

它更像一个确定性的编辑问题。

一个结构化编辑器、AST、LSP，甚至一个普通函数，都可能比让模型重新生成一次代码更加可靠。

这个看起来非常微小的体验，第一次让我开始怀疑一个原本很自然的前提：

模型能力越来越强，是否真的意味着系统应该把越来越多的事情交给模型？

后来在华为实习时，这个问题让我更加的做了系统化的思考。

我接触的场景从网页和普通代码编辑，变成了网络配置、配置诊断。

这类任务和普通生成式任务有一个非常明显的区别：

它们需要高确定性。

配置是否正确，不能够取决于模型“觉得它合理”。但语法是否合法、语义约束是否满足、目标网元当前是什么状态、配置对象是否正确、修改后的结果是否仍然符合业务约束——这里存在大量可以被程序确定和验证的事实。

也正是在这个阶段，我开始越来越多地思考 Agent 的可信性。

最开始，我关注的是模型生成的文件引用是否真的可信。

如果 Agent 告诉用户某个事实来自第 38 行，那么项目发生修改之后，这个引用是否仍然指向同一个语义事实？

后来这个问题逐渐扩展到了更多地方：

Agent 生成的配置是否能够经过真实 Validator？

Agent 声称完成的任务，是否真的满足了完成条件？

Agent 执行错误动作时，最大影响范围是什么？

Benchmark 应该测试整个 Agent System 最终有没有正确完成任务，又如何来判断完成？

但最近重新思考下一代 Agent 时，我开始觉得，它们其实指向同一个更加底层的问题：

我们是不是把太多本来可以由软件确定完成的事情，也交给了概率模型？

我必须强调我怀疑的不是模型的重要性。但我觉得下一代 Agent 的进步，并不意味着模型继续吞掉更多软件逻辑。

当模型已经足够强之后，下一阶段真正重要的问题，开始从：

如何让模型承担更多？

变成：

哪些事情根本不应该再让模型承担？

我可以再翻译一下这个问题——即使模型能够做一件事，这件事也未必就应该继续由模型来做——那么接下来真正需要回答的问题就变成了：

Agent 的自主性究竟应该存在在哪里？

我并不希望因此退回传统的 Workflow。

Agent 最重要的价值恰恰来自它的不确定性：它可以面对一个事先没有完整定义的问题，可以自己探索环境，可以在执行过程中发现新的信息，也可以在原来的计划失效以后重新规划。

真正的问题不是要不要自主，而是今天很多 Agent 的自主性仍然过于“平坦”。

一个任务从开始到结束，往往都处在同一个 Agent Loop 中：

Observe → Think → Act → Observe → Think → Act ...

任务怎么拆、下一步做什么、什么时候并行、什么时候等待、失败以后去哪里、什么时候结束，很多时候都继续存在模型的 Context 里，由模型在每一轮重新决定。这当然非常灵活，但也意味着一个复杂任务即使已经逐渐产生了明确结构，这些结构仍然只是模型脑海里的“想法”，而没有真正成为 Agent 系统的一部分。

最近 Maka 的 Agent Graph 让我觉得，这里可能存在另一种 Agent 形态。

Maka 对 Graph 定义为：

Graph is a schedule, not a second runtime.

它假设 Agent 面对的任务本身就是会在运行过程中不断变化的。

开始时，主 Agent 可能只知道需要调查两个方向；其中一个子任务执行以后，又发现新的代码路径，于是产生新的工作；某个验证结果可能让原来的计划失效，又需要增加新的分支。

这里最吸引我的并不是“Graph”本身，而是它对 Agent 自主性的划分。

Maka 把几种职责分开了：

Main Agent
    ↓
理解目标 / 拆解问题 / 做语义决策
    ↓
Agent Graph
    ↓
记录已经形成的工作关系和依赖
    ↓
Coordinator
    ↓
确定性地推进已经明确的工作
    ↓
Child Agent / Local Agent Loop

主 Agent 仍然拥有真正意义上的自主性。

它可以根据执行结果增加新的工作、废弃原来的路径、调整任务之间的依赖关系。Graph 并没有替它做这些语义判断。

但当一个判断已经形成以后，例如：

A 和 B 可以并行执行； C 必须等待 A 的结果； B 完成后将结果交给 D。

这些已经确定下来的关系，就不需要模型每一次重新从 Conversation 中理解。

它们可以进入 Graph，成为系统能够确定推进的结构。

这也是 Maka 特别强调 Graph 只是 schedule 的原因：Agent 原本的 Runtime、Session、Tool Use 和本地执行仍然存在；Graph 只是把“现在有哪些工作，它们之间是什么关系，什么已经准备好执行”从模型上下文中抽了出来。

我觉得这恰好对应了我前面的问题。

下一代 Agent 并不是在 Agent Loop 和 Workflow 之间二选一。

它可能是：

        开放式 Agent Loop
               ↓
       形成一个阶段性判断
               ↓
    将确定下来的关系写入 Graph
               ↓
      系统推进确定的部分
               ↓
     遇到新的不确定性
               ↓
        再次唤醒 Agent

这样一来，Agent 的自主性就不再是从任务开始到结束始终处于最大值。

它会随着问题状态发生变化。

面对未知时，Agent 可以拥有很大的自由度。

当某些关系已经确定以后，自由度开始收束。

当执行又暴露出新的未知时，系统重新把决策权交还给 Agent。

而它和今天很多纯 Agent Loop 最大的区别在于：

Agent具有确定和自主的转换能力。

于是，一个复杂任务可能不断经历这样的过程：

Unknown
   ↓
Agent Exploration
   ↓
Decision
   ↓
Graph Structure
   ↓
Deterministic Progress
   ↓
New Unknown
   ↓
Agent Exploration

这也是我开始理解“下一代 Agent”的一个重要变化：

Agent 不再只是一个不断运行的 Loop，而开始拥有一个能够承载自己认知结果的结构。

过去，Agent 每一轮思考产生的结果，大量最终只存在于 Context 中。

而 Agent Graph 提供了另一种可能：

一些思考结果不再只是“模型知道了什么”，而可以进一步变成“系统已经知道了什么”。

也正是在这个意义上，我认为下一代 Agent 可能需要的并不是更少的自主性，而是更有结构的自主性。

模型继续负责面对未知、发现关系和改变计划。

而那些已经确定下来的关系，则逐渐从模型的思考中退出，成为 Agent 系统自身的一部分。

这也是我所说的“把确定性重新拿回来”真正想表达的东西。

前面讨论的是如何让 Agent 的自主性不再只是一个无限开放的 Loop，那么自然就会出现问题：

这些结构究竟从哪里来？

你可能会提出最“顺”的答案——“由开发者提前设计”。

但如果所有路径、规则和依赖都在任务开始前被定义好，那么 Agent 最终还是会退化成传统 Workflow。

但同时我也不认为，Agent 在运行过程中形成的所有判断都应该永远停留在模型的 Context 里。

Agent 在执行任务时会不断发现新的东西。

它会确认某些事实，排除一些方向，发现新的依赖关系，也会逐渐找到一条更清晰的执行路径。

这些东西最开始当然需要 Agent 自己探索。

但一旦它们被确认，它们的性质其实已经发生了变化。

它们不再只是：

模型这一轮认为某件事情成立。

而开始变成：

系统已经知道某件事情成立。

我觉得下一代 Agent 很重要的一种能力，就是能够完成这种转换。

未知
 ↓
Agent 探索
 ↓
形成判断
 ↓
得到验证
 ↓
沉淀为结构
 ↓
继续面对新的未知

我暂时把这个过程称为 Progressive Determinization——渐进确定化。

Agent 应该不断把已经被解决的不确定性，从自己的推理空间中移出去。

今天 Agent 的运行方式，本质上仍然是：

Context
  ↓
Model
  ↓
Action
  ↓
新的 Context
  ↓
Model

它的优势是任何时候都可以重新判断。

但这也意味着，即使某些事情已经被确认，模型仍然可能需要在后面的每一步重新阅读、重新理解。

比如：

某个目标对象已经确定；

某个任务依赖已经确认；

某个失败原因已经被排除；

某个修改意图已经非常明确。

如果这些内容之后仍然只是自然语言 Context 的一部分，那么 Agent 实际上还需要不断重新建立对它们的理解。

更重要的是，这会重新引入不必要的不确定性。

所以我现在越来越觉得，一个成熟的 Agent 不应该只是拥有更长的 Context 或更好的 Memory。

它还应该拥有一种能力让已经确认的认知改变自己后续的运行方式。

Maka 的 Agent Graph 正好给出了一个很直观的例子。

Agent 最开始并不知道整个任务应该如何展开。

它先探索。

随着理解加深，它逐渐发现任务之间的关系。

比如模型最开始只是形成一个判断：

A 和 B 可以并行执行，C 必须等待它们完成。

如果这件事情始终停留在 Context 里，那么后面模型仍然需要继续维护和理解这个关系。

但如果它被沉淀进 Graph：

A ──┐
    ├──→ C
B ──┘

那么这个关系就已经从：

模型当前知道什么

变成了：

系统本身知道什么。

这也是我真正感兴趣的地方。

Graph 并不只是让任务执行得更快。

它更像是 Agent 把自己在探索中发现的结构留下来的一种方式。

而且这种结构并不一定只存在于 Graph 中。

Graph 只是其中一个例子。

沿着这个思路继续往下，我觉得今天很多 Agent 在 Reasoning 和 Action 之间连接得有些太直接了：

Natural Language
 ↓
Model
 ↓
Tool Call
 ↓
Action

模型一旦形成判断，下一步往往就是执行。

但如果 Agent 希望把已经形成的确定性保存下来，那么这里可能需要一个中间层。

我暂时把它理解成一种 Agentic IR。

Natural Language
 ↓
Model Reasoning
 ↓
Agentic IR
 ↓
Action

这里的 IR 不一定是一套统一的语言。

它可以只是一个被结构化表达出来的决定。

比如：

修改目标：ServerConfig.timeout
当前值：30
目标值：60

或者：

A 完成以后才能执行 B

Agentic IR 可能是 Structured Agency 和渐进确定化之间一个很自然的连接点。

模型仍然负责形成语义判断。

但判断一旦形成，就不必永远只以自然语言存在于模型的 Context 中。

它可以进入一种更加稳定、可复用的表示。

如果把这些想法放在一起，我现在越来越觉得，下一代 Agent 的核心并不是某一个具体组件。

它更像是一个持续发生的过程。

任务刚开始时，Agent 面对的是大量未知：

████████████████

经过探索，一部分东西被理解：

██████████░░░░░░

继续执行以后，越来越多内容变成系统已经确认的结构：

██████░░░░░░░░░░

最后，真正需要模型继续处理的，是剩下那些仍然开放的问题：

██░░░░░░░░░░░░░░

那些消失的部分并不是被忘记了。

它们只是变成了：系统已经知道的东西。

所以我并不认为下一代 Agent 会简单走向“模型承担越来越多”。

模型能力继续提高，当然意味着 Agent 能够进入更复杂、更开放的未知空间。

但与此同时，一个成熟的 Agent System 也应该越来越擅长保留自己已经获得的确定性。

于是 Agent 的成长可能同时发生在两个方向：

模型越来越强，因此能够探索更远；

以及：

系统越来越成熟，因此不需要重复探索已经走过的地方。

所以走到这里，我现在对自己想构建的 Agent 已经有了一个相对清晰的轮廓。

它不是一个自主性无限扩大的 Agent。

也不是一个被大量规则预先写死的 Agent。

我更希望它能够不断移动 未知与已知之间的边界。

面对真正未知的问题时，它应该足够 Agentic。

它可以探索，可以改变计划，可以发现新的路径，也可以做出开发者事先没有预料到的判断。

但当这些探索逐渐产生可靠结果以后，它也应该能够把这些结果留下来。

变成 Graph。

变成 Agentic IR。

变成约束。

变成已经被确认、以后不需要重新推理的结构。

这也会自然带来一些后续问题：这样的 Agent 应该如何评测、如何验证，以及当它开始拥有越来越强的执行能力以后，安全边界应该怎样定义。关于这些问题，我会在后续文章里继续展开。

但对于这篇文章，我更想停在一个更简单的判断上：

下一代 Agent 的进步，不应该只来自模型对未知世界更强的探索能力。

它也应该来自系统把这些探索不断转化为已知、结构和确定性的能力。

下一代 Agent 会重新向软件工程靠近。