一个朴素但够用的工程框架

42 章经对谈 Sheet0 创始人王文锋这期，适合给 Agent 降温，也适合给 Agent 加一层工程坐标。

它把 Agent 拆成三件事：大语言模型，Context，Tool Use。大语言模型负责理解、推理和生成；Context 负责让模型知道当前任务、历史状态和约束；Tool Use 负责把意图变成外部行动。

这个框架不炫，但好用。很多 Agent 讨论的问题，都能放回这三格里。一个产品失败，未必是模型不够强；可能是上下文乱了，也可能是工具暴露得太粗，也可能是环境反馈没有被系统正确吸收。

这种拆法的好处，是它把 Agent 从「像不像人」拉回「能不能完成工作」。完成工作需要理解，需要记住现场，也需要动手。少了任何一环，系统都会塌。

Context 不是把资料塞满窗口

很多人把 Context 理解成长上下文，仿佛窗口越长越好。长窗口当然重要，但 Agent 的 Context 不能只靠容量解决。

对 Agent 来说，Context 更像工作现场记录。它包括任务目标、用户偏好、历史步骤、当前状态、工具返回、错误信息、权限限制、下一步计划，以及哪些信息已经过期。这里最重要的是「有结构」。

如果 Context 组织不好，模型会出现几类典型问题。

它会忘记任务边界。用户明明只让它整理资料，它可能继续扩展到写报告、发邮件或改文件。

它会重复无用动作。前一步已经失败，下一步又按同样方式重试，只是换一种说法。

它会被旧信息污染。页面状态已经变化，文件已经更新，模型仍然基于旧上下文做判断。

它会不知道什么时候该停。长程任务最常见的问题之一，就是 Agent 在没有明确完成条件时不断继续。

所以 Context 的核心是决定哪些信息进入短期任务状态，哪些信息进入长期记忆，哪些信息需要压缩，哪些信息必须丢弃。

Tool Use 决定 Agent 的手长在哪里

工具使用是 Agent 从聊天走向执行的关键。

但工具不是一个单一概念。Function Call、MCP、A2A、Computer Use、Browser Use、API 集成，常常被放在一起说，实际差别很大。

API 路线最稳定。系统暴露明确接口，Agent 调用结构化参数，返回结构化结果。它适合 CRM、数据库、内部系统和开发工具这类可控环境。

浏览器路线覆盖面更广。很多系统没有好用 API，或者 API 权限难拿，浏览器就成了现实入口。但浏览器页面不稳定，前端结构会变，登录态会过期，弹窗会挡住流程，自动化难度更高。

电脑操作路线最接近人类使用方式。它可以移动鼠标、点击、输入、打开文件，覆盖面最大，风险也最高。只要能操作电脑，就必须认真处理权限和误操作。

MCP 这类协议试图把工具暴露方式标准化。它能降低连接成本，但不自动保证任务成功。工具能被调用，只是开始；工具能被正确选择、组合、重试、审计，才是产品能力。

为什么 AI Coding 总是最先跑出来

AI Coding 在 Agent 讨论中反复出现，因为编程环境最适合 Agent。

代码世界有几个天然优势。第一，反馈清楚。测试过不过、编译成不成功、错误栈在哪里，都能返回给系统。第二，状态可追踪。Git 可以记录差异，文件系统可以比较变化。第三，结果可验收。一个修复是否有效，至少可以通过测试和人工 review 初步判断。

更重要的是，代码是一种能改变环境的媒介。模型会写代码，就不只是调用已有工具，还可以临时生成工具、修补工具、连接工具。某种意义上，代码给了模型一双手。

但这双手也需要约束。能写代码的 Agent 必须有沙箱、测试、权限、回滚和审计。没有这些，它可能会在真实项目里制造难以追踪的问题。

所以 Coding Agent 是样板间，不是终点。其他行业要借鉴的，重点是它背后的反馈流程。

Agent Infra 会先解决脏活

节目里提到的 E2B、Browserbase 这类基础设施，之所以值得关注，是因为它们处理的是 Agent 落地时最不浪漫、但最关键的部分。

Agent 要跑任务，需要环境。环境要隔离，要可复现，要能观察，要能销毁。一个云沙箱可以让 Agent 安全执行代码；一个浏览器运行时可以让 Agent 操作网页；日志和回放系统可以让开发者知道它为什么失败。

这些能力很难在最终用户界面里被看见，但它们决定 Agent 能不能进入生产。如果每个应用团队都要自己搭沙箱、浏览器、任务队列、日志、权限和评估，行业会重复造大量轮子。

基础设施公司的机会就在这里。它们未必拥有最亮眼的前台应用，却可能成为很多 Agent 产品背后的运行层。

如何判断一家 Agent 公司有没有工程含量

看一家 Agent 公司，不能只看演示视频。可以问几个很具体的问题。

  • 它的任务环境是否清楚。
  • 它怎么组织短期 Context 和长期记忆。
  • 它优先走 API、浏览器、电脑控制，还是混合路线。
  • 它如何处理工具失败和环境变化。
  • 它有没有日志、回放、评估和回滚。
  • 它在哪里设置人工确认点。
  • 它的成本是否会随任务长度失控。

这些问题听起来不性感，但决定产品能否从 demo 走向生产。

如果一家公司只能讲「我们接了最强模型」，却讲不清上下文、工具、权限和评估，它大概率还停留在包装层。如果它能把失败路径讲清楚，反而说明团队真的在工程现场里待过。

结论

Agent 开发的上半场，硬仗不在概念，而在 Context 和工具。

模型会继续变强，但每个真实任务都要落到环境里。环境里有旧数据、权限、异常、失败、误操作和人类临时变化。Agent 要在这里稳定工作，必须把上下文、工具、状态、权限、反馈和评估打磨成系统。

42 章经这期的价值，是把 Agent 从热词拉回了工程问题。以后判断一个 Agent 产品，不妨先按 LLM、Context、Tool Use 三格拆开。模型决定上限，Context 和工具决定它能不能在真实世界里完成工作。