ARTICLE · 1132361
同一个大模型,为什么换个 App 就像换了个 Agent?
同一个大模型,为什么换个 App 就像换了个 Agent?碎碎念：之前跑 DeepSeek Harness 时遇到过一个问题：针对我手搓的 iOS 项目debug都完成了代码修改、构建和自动测试，但真机摄像头、快捷指令自动化和人工视觉验收仍然没有完成。工具调用跑完了，离用户问题真的解决，还没有验证。导致交付产物不及预期；那么，为什么有这样的现象，以及如何优化？ From Google：Host -- 提供程序运行的物理/逻辑边界，Runtime -- 提供程序执行的底层技术支撑，而 Harness 则是一个为了特定目的（如测试或调试）将程序、Host 和 Runtime 包装并驱动起来的外部控制工具； 顺着这个问题，本期拆一拆模型外面的系统：Host 和 Runtime 分别负责什么，它们又怎样影响一个 Agent 的实际能力。 01 - 同一个模型，为什么能做的事差这么多？ 先换成一个更简单的例子。假设你给 Agent 的任务是：“修好这个页面上点击保存没反应的问题，并验证修复结果。” 在只有聊天能力的产品里，它能分析你贴出的代码，告诉你可能怎么改。进入具备tool的 IDE 后，它可能直接读取项目、修改文件、运行测试。如果产品还提供浏览器和可用的测试环境，它就有机会打开页面，实际点一下保存按钮。 而，模型可以是同一个，能完成的工作却差了好几步。 模型可以根据输入理解任务，生成回答，也可以输出“调用某个工具、传入这些参数”这样的结构化toolcall。 但这条请求要真正变成一次文件读取、代码修改或浏览器点击，还需要外部程序接住并执行。 回到修 bug 的例子。模型判断“应该先看看按钮的事件处理函数”，接下来至少要解决两类问题： 简单理解，前一类偏向 Host：提供工作环境与访问边界。 后一类偏向 Runtime：组织并推进执行过程。 To clarify：不是所有框架都遵守的两层标准架构。一个 AI 应用完全可以同时承担两类职责，内部也未必有两个独立模块。这里拆开方便更好理解； 尤其是 Host，在 MCP 协议里有明确含义，不能和本文的扩展用法完全画等号。 02 - Host：它能接触哪一部分现实？ 在MCP的官方文档中，Host 指 AI 应用。它协调一个或多个 MCP Client，由 Client 与对应的 MCP Server 建立连接。 比如，一个 IDE 可以作为 Host，通过不同 Client 连接文件服务和数据库服务。这里的 Host 可以包含执行循环，并不只是一个界面或一台电脑。 把视角扩展到整个 Agent 产品，我们可以沿着 Host 这一侧，检查它为任务提供了什么工作条件： -资源：能访问哪个项目、哪些文件、网页和业务系统？ -身份与权限：以谁的身份操作？能读还是能写？哪些动作需要用户确认？ -执行环境：代码在哪里运行？本机、云端容器还是隔离环境？有没有浏览器和必要依赖？ 打个比方，它像一个工程师的工位：仓库有没有拉下来，终端能不能运行，浏览器能不能访问测试站点，账号有没有写权限。 但这里的边界也不只由 AI 应用决定，操作系统、Sandbox、服务端权限和业务规则都可能再拦一道。 还是修保存按钮的问题：如果 Agent 只能读你粘贴的代码，它可能连调用链路都看不全；如果能读写完整仓库，却没有运行环境，它可以改文件，但无法执行测试；如果能跑测试，却接触不到页面，也就缺少实际点击验证的条件。 这些限制，有时换一个更强的模型也解决不了。 模型可以提出合理的下一步，但系统必须提供完成这一步的条件。 03 - Runtime：怎样把一步判断接成连续行动？ 有了文件、工具和权限，任务也不会自动完成。还需要一套运行机制，把模型判断与工具执行接起来。 一次修复过程， 1. 系统把任务、项目说明和当前可用的工具交给模型。 2. 模型请求读取相关代码，Runtime 检查请求，并按权限与策略调度工具。 3. 读取结果返回后，系统把相关内容加入下一轮输入。 4. 模型根据代码提出修改，再请求执行测试。 5. 测试失败，错误信息进入下一轮，模型据此继续调整。 6. 测试通过后，继续检查页面行为，最后汇总改动与验证结果。 这就是 Agent Loop，执行循环。它最核心的部分可以写成： 调用模型 → 处理输出 → 执行工具 → 回传结果 → 再次调用模型。 模型主要负责判断下一步，Runtime 负责校验、调度和推进；预设流程与运行策略也可以限制执行路径（不能把 Runtime 理解成另一个替模型思考的“大脑”） OpenAI agents sdk的runner就是一个具体例子：它调用模型，处理工具调用，必要时把控制权交给另一个 Agent，并在满足相应条件时结束循环。 这个最小循环并不复杂。实际做业务的时候还遇到很多工程问题：上下文太长影响推理rt和效果怎么办，工具超时怎么办，需要用户确认时怎么暂停，中断后怎样恢复。 这些是 Runtime 或相关基础设施可以补充的能力，不是只要有一个 Agent Loop，就会自动具备的能力。 例如，“可以暂停后继续”和“进程崩溃后仍能恢复”是两个要求。后者通常还需要持久化任务状态，并妥善处理恢复时可能重复执行的动作。对有副作用的工具，也不能看到超时就盲目重试，要先考虑它是否已经生效。 还有一个关键区别：循环结束，只代表执行停了，不代表用户目标已经完成。 模型给出最终回答、达到最大轮数、触发超时，都可能让过程停止。至于 bug 是否真的修好了，需要另外验收。 04 - 存下来的文件/信息，不等于模型这一轮看到的内容 修复过程越长，信息就越多：项目文件、历史消息、代码差异、测试输出、浏览器日志…… 即使这些信息都已经存下来了，也不代表模型每一轮都需要看到。 这里有两个概念， State，任务状态：系统保留下来的进度、记录和相关数据。 Context，上下文：模型在这一次调用中实际收到的内容。 比如，测试日志已经保存到文件里，但下一轮输入只写着“测试失败”，没有带回报错位置，模型就很难判断该改哪里。又比如，上下文经过压缩后漏掉了“不要修改公共接口”这个约束，后续动作就可能偏离要求。 因此，“系统记住了”和“模型这次知道”之间，还隔着检索、选择、摘要和组装这几步。 话说回来，状态究竟保存在哪里，取决于实现。可以由应用、Runtime、Session 存储或数据库共同承担，不能简单规定“Host 管存储，Runtime 管读取”。保存了聊天历史，也不代表运行中的进程、文件和外部业务状态都能一起恢复。 工具同样有这道差别。 浏览器工具已经接入产品，不代表当前任务有权限使用；有权限，也不代表这一轮已经向模型提供了它的说明；模型发出了调用请求，还要经过执行和结果处理，才能影响下一步判断。 所以，当我们列出十几个工具时，可以再追问一句：这些工具是否真的进入了当前任务的执行过程？ 05 - Harness、Sandbox、MCP，又是什么关系？ Harness：模型外面的工程配套 Harness 通常指围绕模型搭建的一整套运行与管理机制，可能包括工具、上下文管理、执行循环、日志和评估。 不同团队的用法并不完全一致。有的人说“模型之外全是harness”，所以看到这个词，不能把它当成边界固定的一个标准层。 Sandbox：动作在哪里被隔离执行 Sandbox 是隔离执行环境，可以按配置限制代码对文件、网络和系统资源的访问。 在修 bug 的任务里，它可以让 Agent 在受限环境中运行项目、修改文件和执行测试，降低动作影响边界外环境的风险。但如果你允许它访问真实文件或业务 API，相应动作仍然可能改变真实数据。隔离的强度取决于具体实现与配置。 MCP：外部能力怎样标准化接入 MCP 规定 AI 应用如何与外部服务连接、发现能力和交换信息。Server 除了提供 Tools，也可以提供 Resources 和 Prompts，分别用于暴露上下文资源和可复用的提示模板。 它能帮助产品接入能力，但不会替整个 Agent 定义修 bug 的流程，也不会自动保证任务完成。 接通一个文件服务，只说明有了标准化的连接方式。何时读取文件、读取结果怎样进入下一轮、改完之后怎么验收，仍要由模型与执行系统共同完成。 06 - Agent 没做好，沿着这五个问题排查 说了这么说，理解这套体系最实际的用处是：遇到问题时，能缩小排查范围。 继续用保存按钮的例子，我们可以按下面的顺序检查。 一，它有没有接触到正确的项目环境？ 读的是目标仓库吗？改的是当前运行版本吗？有读取、修改和测试权限吗？如果连项目都没找到，先查环境与访问配置。 二，它有没有看到判断所需的信息？ 相关代码、报错日志和用户约束，是否进入了当前 Context？如果信息缺失，先查检索与上下文组装；信息齐全仍判断错误，再看提示设计和模型能力。 三，工具调用在哪一步断了？ 工具是否对当前任务可用？模型有没有发出请求？参数校验是否通过？工具实际执行了吗？结果有没有返回模型？“没有改动文件”可能对应不同断点，需要看调用记录区分。 四，它为什么重复执行，或者提前停了？ 是不是同一个错误被反复重试？有没有新的信息进入下一轮？停止原因是模型输出最终答案，还是轮数、超时、权限或确认流程阻塞？先把停止原因查清，再决定该调整哪里。 五，验收的是工具action，还是用户最终目标？ 文件保存成功，只能证明改动写进去了。测试通过，也只能证明已经运行的测试没有报错。 对这个 bug，还需要检查：点击按钮后，是否发出了预期请求，页面是否正确反馈保存结果；必要时，进一步确认数据确实被保存。验证不到的部分，要在结果里说明。 这里也能看出 Host 与 Runtime 的配合：环境要提供观察结果的条件，执行过程要安排验证步骤，模型还要正确解释验证证据。 “工具执行成功”到“用户问题解决”之间，可能还需要一次check。 Host 和 Runtime 的区分，能把这些问题拆开，缩小排查范围。同时，工具没用上、action没执行、结果没有反向verify，可能需要三种不同的改法。 回到开头。Agent 最后弹出“已完成”时，我们是拿到了debug后的代码文件？一轮成功的测试？还是用户问题真的已经解决？这些问题比“又接入了多少工具”更重要。
项目文件在哪里？能不能读取和修改？有没有运行测试的环境？
这一轮给模型看什么？工具请求怎样执行？结果回来后，继续查还是可以结束？
个人的判断是：评估一个 Agent 产品，模型仍然是基础，但tool list和产出效果还不够。需要拿一个真实的case，沿着它的执行记录看一遍（完整轨迹）：它接触到了什么，每轮看到了什么，动作是否生效，最后又为什么说“完成了”。