Agent开发上半场：环境、工具与上下文如何决定Agent

# Agent技术：从玩具到工具，一场正在发生的质变 Agent无疑是当下技术圈最炙手可热的话题。围绕这个话题，有一些核心问题值得认真拆解：到底什么是Agent？这波Agent热潮跟过去有什么本质不同？决定Agent成败的关键变量又是什么？ ## 什么是Agent？从定义说起 目前最精准的，恐怕要数Anthropic给出的定义：Agent是让模型基于环境反馈去使用工具的一个程序。 这个定义里藏着三层意思：首先，它依赖大模型；其次，它必须能感知环境反馈；最后，它要有调用工具的能力。缺少任何一环，都算不上真正意义上的Agent。 ## 这一波Agent热，究竟热在哪里？ **23年4月以AutoGPT为代表的那一波**，Agent更像一个炫技的demo，看着很酷，但实际用起来就露怯了——离“解决问题”还差得远。 经过两年发展，情况完全不同了。这波Agent确实能在真实的工作和生活场景中派上用场了。 这种跃迁背后，有两个关键驱动因素。 **一是底层模型能力大幅跃升**。尤其是结合了RL（强化学习）之后，以o1为代表的模型赋予了Agent一种稀缺能力——长程思考。这意味着Agent不再是“一步到位”式的响应，而是能像人类一样，把复杂任务拆解成若干步骤，一步步推进。 **二是工程侧和产品侧的重大突破**。最直观的表现就是，大家更清楚该怎么为Agent搭建一个合适的Context，从而更好地解决问题。 ## Context，才是Agent的灵魂所在 Context指的是大模型执行任务时所需的各种信息的总和。 不同产品的Context千差万别。以Sheet0为例，这是一个Data Agent，核心目标是打通整个数据工作流——从网页上收集数据、处理数据，再到基于数据采取行动。它的Context就包括网页内容、收集整理的数据表格、用户指令，以及分析数据时生成的SQL等。 那Agent中的Context跟其他产品有什么本质不同呢？ **核心区别在于Context的来源。** 传统方式，比如RAG，需要大量人工干预。网页里有很多无关信息需要人工过滤，过程中生成的SQL也需要人工校验准确性。但在Agent中，这些信息会以自动化的形式被提炼出来——整个过程不需要人的参与。 ## 梳理一下各种Tool Use方案 最近Function Call、MCP、A2A、Computer Use、Browser Use这些概念扎堆出现，确实容易让人犯晕。但本质上，它们都在解决同一个问题：**让大模型更有效地通过工具调用（Tool Use）去执行任务。** **Function Call**最早由OpenAI提出，让大模型通过调用外部函数实现Tool Use。但它不太通用——好比+86的手机号在美国就没法接打电话，换个系统就得重做。 于是就有了**MCP**。MCP的核心价值在于“统一了Tool Use的度量衡”，极大降低了门槛。它可以把任务拆解成多个子任务，每个子任务都有模块化、标准化的组件，让大家能够更自由地调用各种工具。 至于Google最近推出的**A2A**，看起来并没有提供新的技术解决方案，更像是大厂为了争夺Tool Use话语权而推的KPI工程。A2A号称自己能实现Agent之间的交互，而MCP只能让Agent通过函数接口调用外部工具。但其实两种交互方式并没有本质区别——Agent本身也有函数调用接口，所以MCP也能间接实现Agent之间的交互。 而**Computer Use和Browser Use**，则是让大模型把电脑和浏览器作为工具来调用。 ## Browser Use：视觉方案与代码方案的博弈 Browser Use本质上是让Agent通过GUI与网页交互。具体来说，后端大模型收到浏览器截图，判断上面的交互元素、推算坐标，然后在前端模拟人类的操作——移动鼠标、点击、输入，就像Agent真的在使用浏览器一样。 但纯视觉的方案，坦白说，还远远不够成熟。国外有家叫Adept的公司，23、24年很火，就是走这条路，现在已经死了——因为这事太难了。 所以实际上，现在大家调用Browser Use时，通常需要MCP作为中间媒介。把浏览器的API包装成MCP组件，通过代码驱动完成后续操作。也就是说，Agent在前端给用户演了一场戏——看似在模拟人类操作，背后还是代码在驱动。 那未来会不会因为有些公司不兼容MCP，甚至为了保护用户数据拒绝兼容，导致大家不得不依赖模拟人类的方式来使用浏览器呢？ 其实关键在于SaaS软件有没有Open API——因为任何Open API都可以被包装成MCP来使用。在国外，Open API基本是标配，所以MCP的适用范围很广。但国内情况完全不同，大多数公司还没有开放Open API或SDK，这条路径确实被堵住了。 **所以结论很清楚**：如果公司开放后端接口，就可以直接通过代码调用工具；如果不支持，就只能通过视觉和模拟人类使用电脑的方式。 这两种方案各有利弊。视觉方案在稳定性和准确度上还不够——比如给LLM的截图里有个提交按钮，它经常算错坐标。但优势是成本低、速度快，消耗的token至少少一个数量级。具体怎么结合，需要开发者根据实际需求调整配比。 ## Agent为什么要在前端“演”这一出？ 有个专业做Agent算法的人问过一个问题：为什么Manus要用Browser Use？在他的理解里，只要后端代码能打通，就能直接解决问题，没必要在前端搞个浏览器窗口。 答案其实关乎一个关键问题：**怎么给用户营造“可信的氛围感”？** 让人看到Agent执行任务的全过程，是建立信任的重要手段。浏览器天然对人更友好，远比代码界面那种黑乎乎的窗口生动、直观。说到底，用户需要感受到自己在掌控一切——不安全感是人的本性，透明化就是消除这种不安的关键。 ## 垂直Agent时代，而非通用Agent时代 现在市场对Agent的讨论，很像两年前LLM那一波。当时大家都在争论未来属于通用AGI还是垂直模型。如今同样的争论在Agent领域重演。 可以肯定的是，**我们现在处于，并将长期处于垂直Agent的时代**。 用做饭来打个比方：很多人都会做饭，但充其量是拿出手机、打开菜谱、照着做。而一个好的Agent就像五星酒店大厨，受过专业训练，不需要菜谱，做出来的菜色香味俱全。人家是大厨，我们只是会做饭的普通人。 ## AI Coding与Agent会殊途同归吗？ 最热的两个赛道——Agent和AI Coding——表面上井水不犯河水，但越来越有融合的趋势。很多Agent在用AI Coding的方案，而AI Coding那边也在讲Coding是一切基础设施。 理论上，如果要做Browser Use，完全可以让AI Coding直接做出一个浏览器然后自己去用。但理论和现实之间，隔着巨大的经济成本和时间成本。 AI Coding只是大模型执行任务的强大工具，但它有两个关键问题：一是很难与其他工具协同，二是很难复用。如果用AI Coding直接执行任务，需要对每个子任务逐一写出能运行的程序，每遇到新任务都得从头再来——效率低，成本高。 对于Agent来说，最优策略是执行任务时先看看手边有没有现成的工具，实在没有，再考虑用AI Coding现场造。 ## RL与Agent：不可分割的关系 Agent这个概念本身就源于RL。不理解RL，就很难理解Agent到底是什么。 RL中的Agent有三个要素：状态（对应Context）、行动（对应Tool Use）、激励信号——当LLM采取行动后，用于评估每一步效果、指导下一步行动的反馈信号。 对创业公司而言，关键是在产品中打造出好的“环境”。这个环境需要清晰地描述当前状态、Agent可采取的动作（行动空间），以及对结果好坏的定义。 其中行动空间决定了Workflow中要有多少个节点。而定义好结果，才有可能设计出有效的评估体系和激励机制，让Agent基于动态反馈自我迭代。否则整个系统无法收敛——要么给出质量很差的结果，要么“什么都会一点什么都不精通”。 建议所有Agent开发者和产品设计者去读一下强化学习之父Richard Sutton的《Reinforcement Learning: An Introduction》。读完这本书，你会获得一种mindset，在产品设计时能不断思考、调整、定义自己的环境。 ## Workflow会被Agent取代吗？ 不会。**Workflow和Agent会长期共存。** 两者的本质区别在于：Workflow由人类驱动，Agent由AI驱动。人驱动的好处是稳定可靠，但缺乏泛化能力，比较死板。AI驱动则相反——更灵活，能应对计划外的问题，但不确定性高，10次里可能5次会搞砸。 所以Agent适合解决世界上20%更开放、需要长期探索的任务，其余80%日常问题，用Workflow完全足够。 ## 一个非共识认知：Chat是Agent最重要的交互入口 对于Agent而言，用户交互的**自由度**是第一重要的事情，重要性远高于交互的准确度。 限制用户的自由度，实质上是让用户来适应你的产品，加重认知负担。好的Agent应该足够智能，让用户像小朋友一样自由地使用。现有交互方式中，Chat就是最能保障交互自由度的形态。 当然，准确度也很重要，但这不是用户该承担的问题，而应由开发者和产品设计者去解决。业界有很多提升准确度的方法：引入Human-in-the-loop、像Devin和Manus那样积累用户偏好、通过提问引导用户细化需求等等。 不必在前端堆砌太多组件。可以在恰当的时机把合适的组件推到用户面前。即使设计了200个组件，每个用户可能只用得上其中10个——没必要把200个全摆出来，徒增认知负担。 ## 理解用户，从Context开始 想更好地了解一个人，就要看他的过去。同理，想理解用户意图，就要追踪他从哪里来、沿途经过哪些路径。 这就好比下围棋：当前这一步没那么重要，重要的是理解对方前面一百手是怎么下的。只有这样，才能判断整盘棋的思路，推测下一步策略，做出相应动作。 Google很早就在保存用户cache，这确实是它在AI Native时代最大的竞争优势——海量用户点击数据，未来都可以用在意图识别中。 ## 开发者要解决两个信任问题 **第一，要信任大模型的能力。** 如果不信任，就会退回到rule-based的老路，加一堆限制条件。这其实是在人为限制模型的泛化能力，导致Agent对模型智能的利用率大大降低。 **第二，要通过产品设计让用户信任Agent的结果。** 这方面最典型的例子是DeepSeek R1。在R1之前，拿到AI生成的报告，第一反应往往是“这靠谱吗？”——因为不知道报告怎么来的。但R1第一次让人看到了推理过程，心理上就更有安全感。Manus也是类似的机制。 ## 从定性到定量：Agent的底层差异 区分Agent，最终要看它交付什么。市面上的Agent大体分两类：Coding Agent交付可执行的代码；调研Agent（如GenSpark、Deep Research、Manus）交付报告。 表格Agent跟它们相比，本质上是“定性分析”和“定量分析”的差异。 定性分析能帮你建立对问题的感知，但不能提供精确数据。而Sheet0想解决的是那些对精确度有要求的场景——比如需要一个精准的数字，就需要准确的数据源，通常是清晰完整的表格。借助AI从数据源抓取数据、汇总到表格、再去做下一步分析——同时在工程上解决模型幻觉问题，保证准确度。 ## AI Coding是大模型的“灵巧手” 大模型执行任务的过程有多步，最终准确率是前面所有步骤准确率的乘积。如果每一步成功率都是90%，连续10步之后整体成功率可能只有35%。 为了解决这个问题，可以在每步中引入AI Coding，把难以评估的结果转化为可验证的代码。比如每步生成10段代码，即使只有一半正确也没关系——只留下正确的那5段，生成正确的阶段性结果，再进入下一步。这样就保证了100%的准确率。MCP也是通过这个方案打通了工具调用之间的壁垒。 ## 如何判断一家Agent公司的好坏 如果有人问Agent公司做得好不好，首先可以看团队里有没有人读过《Reinforcement Learning: An Introduction》——因为这往往意味着他们具备一种正确的mindset。 更重要的是，可以问他们怎么设计产品中的激励信号——也就是怎么评估结果的好坏。这决定了大模型能不能往更好的方向持续迭代。比如执行过程中生成的表格里“数据是否为空”，本身就是一种直观的反馈信号。或者通过AI Coding把难以直接评估的结果转化为可验证的代码——脚本能不能成功运行，也是种激励信号。 Agent要想有突破，至少需要模型更强了，或者Context工程走得更远了。抓住这两个关键变量，才能判断方向是否正确。