编码智能体的运行机理

第3章　编码智能体的运行机理

本章将视角从前两章的人机协作模式与智能体能力边界，进一步推进到编码智能体的内部运行机制。前两章回答了智能体是什么、能够做什么以及不能做什么，本章则进一步追问，这些能力究竟是如何产生的。

本章首先介绍大语言模型作为推理引擎的基本工作方式，并说明这种基于概率生成的推理与传统形式逻辑系统之间的根本差异。在此基础上，进一步分析智能体执行编码任务时所遵循的循环结构，以及模型本身与负责提供工具、上下文、状态管理和执行环境的软件系统为什么必须区分开来。最后，本章将这些机制落到一个可以观察和衡量的问题上：智能体能够在多大程度上独立完成一项复杂任务，以及这个能力边界正在以怎样的速度扩展。

读完本章，读者能够从机制层面描述一次编码智能体任务的执行过程，理解模型、工具、环境与反馈之间如何共同构成一个完整的执行循环，而不是停留在“模型好像在思考”这样的模糊描述上。

3.1　LLM作为推理引擎：概率生成与链式思考

智能体之所以能够规划任务、作出判断并决定下一步调用什么工具，核心依赖的是作为推理引擎的大语言模型。要理解智能体的能力边界，首先需要理解这个推理引擎究竟是如何工作的。

从计算机制上看，大语言模型的基本任务可以概括为下一词元预测，如图3-1所示。给定一段上下文，模型会根据当前状态计算词表中不同候选词元出现的概率，再依据相应的解码策略选择下一个词元。新生成的词元会立即成为后续预测的一部分，模型就这样逐步生成后续内容，直到满足停止条件。这个过程背后涉及参数化表示、注意力机制以及大量训练数据形成的统计模式，但从输出机制来看，仍然是一个不断预测和生成下一个词元的过程。

图3-1　大语言模型生成一次回应的处理流程

这种机制容易让人产生一个误解。既然模型能够完成数学推导、程序设计甚至复杂的任务规划，它是不是在内部运行着类似人类的逻辑推理过程？这个问题需要谨慎回答。大语言模型确实能够表现出明显的推理能力，但这种能力并不意味着模型内部存在一个与传统形式逻辑系统等价的、可以被直接观察的推理程序。

一些研究尝试直接询问模型自己是如何完成推理的。不同模型给出的回答虽然措辞各异，却经常呈现出相似的结构，例如先拆解问题，识别任务目标、关键概念和约束条件，再调用训练过程中形成的相关知识模式，随后组织这些信息，最后生成答案。这种描述与人类对“分析问题—回忆知识—组织论证—形成答案“的直觉理解十分接近。

但这里需要特别谨慎。模型对自身推理过程的描述，本身也是模型生成的文本。它并不是一份能够直接读取模型内部计算过程的日志，也不能简单视为模型对自身机制的权威说明。模型能够生成一段看起来合理的“思考过程”，并不意味着这段文字逐步骤对应了内部真实发生的计算。更合理的理解是，这类自述本身也是模型根据训练中形成的语言模式，对“如何解释推理过程”这一问题生成的回答。

因此，研究模型推理机制时，更有价值的是观察它在不同任务上的实际行为，而不是把模型生成的自我解释当作内部机制的直接证据。不同模型在解释推理时表现出的结构相似性，至少说明训练数据中存在大量关于问题求解、论证和推理的共同语言模式，但不能据此断定它们内部采用了完全相同的认知过程。

链式思考（Chain-of-Thought）是理解这种能力的一个重要切入点。当模型在回答复杂问题时被要求显式生成中间步骤，其多步骤任务的表现往往会得到提升。一个重要原因在于，模型生成的每个词元都会进入后续预测的上下文。模型写下一个中间步骤之后，这个步骤就成为下一步生成的条件，相当于把原本需要一次完成的复杂映射拆成多个连续的局部预测。

例如，一个复杂的数学问题可以被展开为“识别已知条件—选择公式—代入参数—计算中间结果—得到最终答案”等多个步骤。每一步生成的结果都会为下一步提供新的上下文，使模型不必直接从问题跳跃到最终答案。对于编码任务也是如此，模型可以先分析需求，再定位相关文件，提出修改方案，最后生成具体代码。中间步骤本身成为后续生成的条件，从而扩大了模型处理多步骤任务的能力。

不过，这并不意味着模型因此获得了与人类相同的思维过程。更准确地说，链式思考利用了自回归生成机制的一个重要特性，把复杂任务转化为连续的条件生成过程。模型并不是因为先写出了推理步骤才开始推理，而是这些中间生成结果为后续预测提供了更多结构化上下文，从而使复杂问题更容易被逐步处理。

这一点对于理解编码智能体尤其重要。智能体后面所表现出来的规划、工具调用和任务分解能力，并不是一个独立于大语言模型之外的“思考模块”突然出现，而是在语言模型的生成能力基础上，通过上下文、工具和反馈机制不断延长和组织这个生成过程。

3.2　推理的本质边界：模式预测与符号逻辑的差异

上一节说明了链式思考为什么能够提升复杂任务的处理能力，本节进一步讨论这种能力的边界。要理解编码智能体为什么有时表现得像是在严密推理，有时却会犯下看似低级的错误，需要区分两种不同的计算范式。

符号逻辑系统，例如自动定理证明器和逻辑编程语言，操作的是形式化的符号，并按照预先定义的规则进行推导。在前提、规则和推导过程都满足要求的情况下，系统得到的结论具有形式意义上的确定性。大语言模型则采用完全不同的机制。它从大量训练数据中学习语言、代码以及问题求解过程中的统计规律，根据当前上下文预测后续最可能出现的词元，并通过连续生成形成最终结果。从这个意义上说，大语言模型的基本机制不是传统意义上的符号演绎，而是基于模式学习的条件生成。

这种差异在实际使用中并不总是容易察觉。当训练数据中存在大量高质量的代码、推导过程和问题求解示例时，模型可以复现其中高度稳定的结构，使最终输出与经过严密推理得到的结果非常接近。对于使用者而言，两者的外在表现可能几乎没有区别。但这种相似并不意味着模型内部运行着与形式逻辑系统相同的推导过程。模型是在已学习的模式空间中生成结果，而不是按照一套显式的逻辑规则逐步证明结论。

因此，模型的表现通常与任务是否存在成熟、稳定的模式高度相关。对于常见算法、标准库用法、主流设计模式以及文档完善的技术方案，训练数据往往提供了大量相似案例，模型更容易生成符合预期的结果。相反，当问题涉及新的逻辑组合、项目内部特有的业务规则，或者需要在多个相互冲突的约束之间作出没有现成先例的取舍时，模型更容易出现偏差。更值得注意的是，这种偏差未必表现为明显的错误，可能只是一个看似合理的假设、一处不易察觉的语义偏移，或者一个与项目实际约束并不一致的架构选择。

对于编码智能体而言，这种边界直接影响任务应该如何委托。生成标准接口实现、补充常见设计模式的样板代码，或者按照既有代码结构扩展一个相似模块，通常属于模式高度成熟的任务，模型更容易得到可靠结果。但如果任务涉及项目特有的业务规则、没有先例的架构决策，或者需要在多个隐含约束之间进行权衡，模型生成的方案即使语法正确、命名规范、结构清晰，也可能在语义层面偏离真实需求。

这正是“看起来正确”和“真正正确”之间最容易出现落差的地方。代码能够运行，只能说明它满足了某些可观察条件，并不能证明它实现了真正的目标。对于编码智能体而言，编译通过、测试通过甚至静态检查通过，都只能提供不同层次的证据，而不能自动等同于语义正确。

这也是本书反复讨论可信性的一个重要技术根源。既然模型生成的是基于上下文的概率性结果，而不是经过形式化证明的结论，那么对生成结果的信任就不能建立在“模型看起来很有把握”之上，而需要建立在独立的验证证据之上。第9章讨论的独立验证原则，正是针对这一根本限制提出的工程化回应。

3.3　智能体循环：从计划到验证的控制回路

智能体执行真实的软件开发任务时，并不是把整个问题一次性交给模型，然后等待它生成一份完整方案。更常见的情况是，任务被不断拆解、执行、检查，再根据新的信息调整后续行动。第2章已经从ReAct的角度勾勒出“观察—推理—行动”这一基本循环；本节在此基础上，把智能体执行编码任务的过程进一步展开为四个相互衔接的阶段：计划、行动、观察、验证。理解每个阶段分别解决什么问题，比单纯记住这四个名称更重要。

计划阶段负责将一个相对模糊的目标转化为范围明确、依赖关系清楚并具有验收标准的工作单元，解决的是“究竟要完成什么”的问题。计划越清晰，后续执行越不容易偏离目标。

行动阶段负责把计划转化为实际操作。harness为模型提供必要的工具和执行环境，使模型能够在一定范围内自主读取代码、编辑文件、运行命令，而不需要人在每一个步骤之间介入。模型由此不再只是生成代码建议，而是能够直接改变任务所处的真实环境。

观察阶段负责把行动产生的新信息重新纳入决策过程。测试输出、错误信息、命令执行结果、文件差异以及运行状态，都会成为下一轮判断的输入。没有观察，智能体只能按照最初的计划机械执行；有了观察，它才可能根据环境反馈调整行动。

验证阶段解决的是生成结果的可信性问题。模型产生的代码终究只是一个候选结果，能否接受不能由模型自己的判断决定，而需要依靠测试、静态分析、代码评审以及其他独立证据进行核验。换句话说，“模型认为已经完成”与“任务已经被证明完成”是两件不同的事情。

这四个阶段共同构成的是一个控制回路，而不是四个彼此孤立的步骤。真实的智能体任务始终面临多重不确定性：模型行为具有概率性，代码库的实际状态可能与任务描述存在偏差，任务范围过大或定义含糊都可能导致执行方向逐渐偏离，而模型生成的结果即使表面上完整，也未必真正满足要求。计划负责划定边界，行动负责调用工具并改变环境，观察负责获取新的状态信息，验证则引入独立证据。四者不断循环，才能将一个原本具有较大不确定性的执行过程转化为相对可控、可追踪的工程过程，如图3-2所示。

图3-2　智能体循环的四个阶段与外部压力来源

这里的“循环”是应用层面的控制结构，而不是模型自身存在一个对应的认知周期。计划、行动、观察和验证这些阶段，是由包裹模型的外部软件系统组织起来的。模型本身并不知道自己正在执行“计划阶段”还是“验证阶段”，每次被调用时，它仍然是在给定上下文的基础上预测并生成后续输出。

这个区分非常重要。它意味着我们不能简单地把智能体描述成一个会思考的模型，而应该把它理解为模型、工具、上下文、执行环境和控制逻辑共同构成的系统。下一节将进一步讨论模型本身与这个外部系统之间的关系，以及为什么理解harness对于判断编码智能体的实际能力至关重要。

3.4　模型与harness的区分

上一节提到，计划、行动、观察和验证这一整套结构并不是模型本身固有的认知过程，而是由模型外部的软件系统组织起来的。要理解编码智能体究竟如何工作，就必须把模型与这套外部系统明确区分开来。

模型本身可以理解为一个概率化的生成引擎。它接收输入上下文，根据参数计算后续词元的概率分布，并逐步生成输出。模型本身不会主动读取代码文件，也不能直接运行命令，更不会在没有外部系统驱动的情况下自行决定下一步做什么。每一次行动，都需要由外部程序发起调用，并将相关信息作为上下文提供给模型。

真正让智能体能够读取文件、执行命令、解析结果并持续推进任务的，是包裹在模型外部的一套软件系统。这套系统通常被称为harness。它负责组装每次模型调用所需的上下文，将可用工具及其调用方式提供给模型，解析模型返回的结果，执行经过授权的操作，将操作结果重新纳入下一轮上下文，并根据任务状态决定是否继续循环或者结束任务。

因此，可以把二者理解为两个不同的层次，如图3-3所示。模型提供生成和推理能力，harness负责把这种能力组织成可以持续运行的任务执行过程。模型决定在当前上下文下应该输出什么，harness则负责什么时候调用模型、提供什么信息、允许它使用哪些工具，以及如何处理它输出的行动。前者具有概率性，后者则承担了更多确定性的控制职责。

图3-3　模型与harness的分层关系

这一划分并不是纯粹的概念区分，它直接解释了为什么同一个模型接入不同的harness之后，实际表现可能出现明显差异。如果harness提供的上下文不完整，模型即使本身能力很强，也可能无法准确理解任务；如果工具接口设计不合理，模型可能难以有效操作代码库；如果缺少反馈和验证机制，模型生成的错误也可能持续积累。因此，智能体任务的最终表现并不能简单归因于底层模型的能力。

软件工程智能体（SWE-agent）这项研究已经提供了较为直接的证据。SWE-agent的研究重点之一，就是如何设计更适合语言模型操作软件工程环境的接口。研究者在不改变底层语言模型的情况下，为文件浏览、代码编辑和命令执行等操作设计了面向智能体的交互接口，使模型能够更加有效地探索代码库、修改代码并获得环境反馈。在真实代码库任务上的实验结果表明，合理设计的接口能够显著提升模型完成软件工程任务的能力。

这个结果说明，一个编码智能体的能力并不只是底层模型能力的简单映射。模型决定了智能体能够达到的能力上限，而harness在很大程度上决定了这些能力能否被有效发挥出来。模型可能已经具备理解代码和解决问题的能力，但如果没有合适的上下文、工具和反馈机制，这些能力就很难转化为可靠的任务完成能力。

这一点也会影响读者理解本书后续内容的方式。第10章讨论的工作台、第19章之后涉及的工具与环境选择，都建立在模型与harness的这条分界线上。评价一个编码工具的实际能力时，不能只问“使用了哪个模型”，还需要进一步观察它如何管理上下文、如何设计工具接口、如何控制执行权限，以及如何组织测试和验证。换句话说，选择一个编码智能体，本质上并不只是选择一个模型，而是在选择“模型+harness”这一整套执行系统。这也是理解当前各种编码智能体产品能力差异的一把重要钥匙。

3.5　能力度量：时间视野的指数增长

前面几节讨论的是智能体运行的内部机制，本节回到一个更实际的问题：智能体目前究竟能够独立完成多长、多复杂的任务，这一能力又在以怎样的速度变化？

一家专门研究和评估人工智能能力的机构METR提出了一种相对直观的度量方法。它不直接统计模型答对了多少道题，而是以人类专业人员完成同类任务通常需要的时间作为参照，考察模型在50%的成功率下能够独立完成多长时间尺度的任务。这个时间长度被称为时间视野（task horizon），可以用来描述模型能够可靠处理的任务复杂度范围。

METR采用这一方法对2019年以来的多代前沿模型进行了持续评估。结果显示，模型的时间视野在过去几年里总体呈现出明显的指数增长，而不是稳定的线性增长。早期估计认为，这一指标大约每7个月翻倍；METR在2024年之后的观测中发现，翻倍周期进一步缩短到约4个月。这意味着不仅任务时长在增长，能力增长的速度本身也可能在加快。截至本书写作时，前沿模型在这项测试中的时间视野已经从早期的分钟级逐渐进入小时级。几年间，这一指标跨越了多个数量级。由于模型和评测结果更新非常快，书中不宜固定某一个具体数值。读者如果希望了解最新结果，应以METR官网的实时数据为准（https://metr.org/）。

不过，这一趋势值得重视，也需要保持必要的审慎。METR指出，目前测试集中超过16小时的任务样本仍然较少，因此对于更长时间视野的估计，统计不确定性明显增加。模型是否能够稳定完成持续数天甚至数周的复杂任务，现有数据还不足以给出有力结论。类似地，当前观察到的指数增长能否长期延续，未来是否会因为任务难度、可靠性或其他因素出现增长放缓，目前也没有确定答案。这里需要区分两件事情：我们可以观察到一条正在发生的增长曲线，但不能仅凭这条曲线推断它将无限期延续。

对本书读者而言，METR研究真正有价值的地方，并不是记住某个具体的小时数，而是提供了一种量化和持续追踪智能体能力边界的方法。过去人们常用“这个模型大概能做什么”来描述能力，而时间视野提供了一个更具体的尺度：对于某一类任务，模型能够在多长的任务周期内保持足够高的独立完成率。

这也意味着，智能体适合承担什么任务并不是一个固定不变的判断。第10章讨论人类监督应该设置在哪些节点，第11章讨论哪些任务适合交给智能体，背后都依赖同一个动态问题：当前这一代智能体能够独立、稳定地完成多长时间尺度的工作？随着模型能力和harness不断演进，这条边界也会持续移动，因此任务分配和监督策略也需要随之重新校准。

本章要点

（1）大语言模型的核心机制，是根据给定上下文预测下一个词元的概率分布，并逐步生成输出。这一过程不同于符号逻辑意义上的推理，但已经足以支撑复杂的多步骤任务。

（2）模型对自身推理过程的自述同样是模式生成的结果，不能视为对内部机制的权威说明。更值得关注的是，不同模型在描述自身工作方式时呈现出的结构性一致。

（3）链式思考之所以能够提升多步骤任务的表现，是因为生成的中间步骤会成为后续预测的上下文，将一次困难的直接推断拆分为多个更容易处理的局部预测。

（4）模式预测与符号逻辑推理属于不同的计算机制。当问题存在大量成熟的训练模式时，模型通常表现较为稳定；当任务需要新颖的逻辑组合或缺乏相似先例时，输出质量可能出现难以预期的下降。

（5）智能体的任务执行通常形成由计划、行动、观察、验证构成的控制回路。这一回路是由包裹模型的软件系统组织起来的应用层结构，而不是模型自身存在的认知周期。

（6）模型提供概率化的生成与推理能力，harness负责将这种能力组织成实际的任务执行过程。同一个模型接入不同的harness后，在上下文管理、工具使用和任务完成率等方面可能表现出明显差异。

（7）METR提出的时间视野指标显示，智能体能够独立完成的任务时长近年来呈现指数增长，部分观测还显示增长速度有所加快。但对于长时间任务，目前的测试样本仍然有限，相关估计具有较大的不确定性。

（8）智能体的能力边界是一个随模型、工具和运行环境持续变化的动态指标。具体数值很快会过时，真正值得掌握的是时间视野的测量方法、适用范围以及长期变化趋势，而不是某个特定时刻的数字。

延伸阅读

[1] Thomas Kwa等，《Measuring AI Ability to Complete Long Tasks》。提出时间视野这一度量方式，链接：https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/.

[2] John Yang等，《SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering》，2024年。该论文提出智能体计算机接口概念，链接：https://arxiv.org/abs/2405.15793。

[3] 开源社区项目，《Agentic Coding：AI Agents Write Code，You Still Ship Software》。该项目适合进一步了解智能体循环以及模型与harness之间的关系，链接：https://agenticoding.ai/。

[4] Antonio Gullí，《Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems》附录F，2025年。该书向多款主流模型提出相同的问题，请模型自述自身的推理过程，完整阅读可以看到不同模型对同一问题的回答及其结构上的异同，ISBN：978-3032014016。