编程智能体如何工作：模型、工具与运行框架循环

什么是智能体运行框架，它为什么影响编程？Claude Code、Codex 和 Cursor 都包含把模型连接到工具并管理工作的运行框架。我开发的 T3 Code 主要是在已有框架之上的界面。我会解释这个循环，并构建一个小示例。

我引用 Matt Mower 的一项功能实现评测：Opus 在 Claude Code 中得分约 77%，在 Cursor 中约 93%。这个比较提示周围的设置可能很重要，但它不能确立普遍排名，也未必隔离了所有配置差异。

运行框架是智能体工作的软件环境与工具集合。语言模型依据输入生成响应，不能独立在你的电脑上运行命令。周围的程序必须提供读取文件、运行 shell 等操作的接口。

为了说明原理，我虚构了一个 bash-call 标签。模型按约定格式发出请求，运行框架识别后，在权限允许时用普通代码执行命令。真实服务商通常使用结构化的工具调用字段，而不是这个虚构的文本语法。

如果我询问目录里有哪些文件，智能体可以请求列出目录，再描述结果。当我要求编辑文件时，运行框架可能在执行写入前请求许可。权限判断和执行都是周围软件的职责。

工具运行后，输出会加入对话，再通过一次模型请求继续任务。模型可能调用另一个工具，例如读取某个文件；循环反复进行，直到获得足够的信息来回答。有些系统会批量或并行调用工具，这个例子只说明基本模式。

运行框架决定有哪些工具、如何描述工具、怎样返回结果，以及适用什么权限。这些选择会影响模型可采取的操作和上下文。模型使用请求及工具提供的信息，也依赖训练中学到的知识。

在项目中打开智能体，并不会让它自动知道每个文件的内容。在我的示例中，它搜索目录、读取 package.json 和相关应用文件，再根据返回的文本解释项目。每次搜索或读取都提供了对话中原先没有的证据。

CLAUDE.md 等项目指令文件可以根据运行框架的加载规则，在会话开始时提供有用上下文。在我的演示中，指令文件让模型无需进行同样的探索就能回答。这些文件是上下文，并不自动保证信息准确或保持最新。

对话历史可以减少重复搜索：智能体能够复用同一会话中已经返回的信息。当我明确指出 package.json 时，它先读取文件，再进行更有针对性的搜索。这是一个例子，并不保证每次提示都能把调用次数减半。

是否应该总让模型一开始读一大堆文件？我通常更愿意让有能力的智能体搜索任务所需内容，同时在自己知道相关线索时提供提示。工具调用也有成本和延迟，因此合适的平衡取决于任务和环境。

较早的工作流有时会把整个仓库打包成一个文件交给模型读取。这在受限环境中可能有用，但也可能带入大量无关上下文。有针对性的搜索让智能体逐步选择证据，而不必假设整个仓库都要装进一个提示词。

我展示了一张长上下文检索图，说明上下文增大可能带来性能下降。表现会受模型、任务和信息位置影响；这张图不能证明更长上下文总会让所有模型变差。实际经验是针对工作负载进行测量，并有意识地提供相关信息。

为了把循环讲具体，我参考 Amp 团队和 Mihail Eric 的文章，介绍一个小型编程智能体。用户给出任务，模型提出一个或多个工具调用，程序执行后将结果返回模型。这个核心循环远比成熟的生产级编程产品简单。

这个简单实现有列文件、读文件和编辑文件的函数。读取函数解析路径并返回内容；列表函数返回名称和类型。编辑示例用新文本替换旧字符串，或写入新文件。真实系统需要仔细处理路径、错误和权限。

工具注册表将名称映射到函数。模型还需要描述和参数信息，才能请求使用工具。在教学示例中，系统提示词列出工具，并要求用包含 JSON 参数的特定文本格式响应；运行框架解析响应，再分发给相应函数。

程序把系统内容和对话发送给 API。收到响应后，它检查工具调用：没有调用就显示答案；有调用则运行请求的函数，附加结果并再次请求模型。正是这个循环将文本响应变成了交互式工作流。

我用另一个智能体构建了一个最小版本，然后让它读取自己的 Python 代码。它通过列出和读取文件来回答。第一次生成的版本落在了意外目录，提醒我们即使是演示也要检查工作目录和输出。

Shell 工具可以运行列出、读取和修改文件的命令，因此能替代多个专用工具，让演示更加精简。但这本身并不是安全的生产设计：无限制的 shell 执行会赋予程序广泛权限，真实框架需要适当的权限控制和防护。

许多模型 API 提供专门的结构化工具接口。服务商或路由服务会将工具定义转换成模型期望的格式。用提示词构造的玩具语法有助于教学，但不能把它当成所有模型服务商的实际协议。

在另一轮对话中，我让这个简单智能体简化自己的环境加载代码。它读取相关文件，并用 shell 命令修改。运行框架允许时，模型可以修改驱动它的程序，但结果仍需要检查和测试。

为什么同一个模型在不同运行框架中可能表现不同？可用工具、描述、系统指令和返回输出都会影响它的选择。在我的小示例中，我修改读取工具描述，建议使用 bash，但模型起初仍选择读取工具。

当我把读取工具标为 deprecated，后一次运行改用了 bash。即使不改变工具实现，修改描述也能引导行为，但单次运行不能证明模型遵循该描述的可靠程度。不同模型对相同措辞也可能有不同反应。

接着我让读取工具返回虚构字符串，而非真实文件内容。模型把这个字符串当作代码来总结。这说明了一个信任边界：工具输出是提供给模型的观察结果，错误或恶意输出都可能误导它。

我用另一种模型尝试同样的 deprecated 工具描述，观察到不同的工具选择。我认为 Cursor 投入了大量工作，针对不同模型测试和调整提示词及工具。评测和演示说明值得研究框架设计，但不能证明每个竞争对手的内部实践。

T3 Code 本身提供界面；选择相应服务商时，它把工作交给本机安装的 Claude Code 或 Codex 运行框架。对于这些后端，它并没有实现示例中的同一套工具循环。构建基本循环并不难，但围绕它做出可靠、易用的产品是大得多的任务。

这个练习的目的是让各个环节变得可见：模型请求、上下文、工具描述、执行和返回结果。理解循环之后，就能更有效地追问智能体为何选择某个工具、它知道什么，以及环境如何影响结果。