Agent TARS

We have released agent tars. Machine Vision!

Comet is here. A web browser built for today’s internet.

Agent TARS 团队的设计原则关键认知 - 团队在构建这款多模态 AI Agent 时遵循三大设计原则：Context Engineering、Observable and Evaluable、Easy to Build Applications 三个设计原则概括来说： 1. 如何管理复杂的上下文：通过动态窗口、多级记忆和压缩策略，解决上下文溢出问题，确保长期运行 2. 如何让 Agent 可控：通过 Snapshot 和自动化评测，让 Agent 的运行透明且可验证 3. 如何降低开发门槛：通过 Agent Event Stream，让开发者能轻松构建应用，同时保持架构的灵活性 1. Context Engineering（上下文工程） 核心理念：要让一个 AI Agent 能长时间稳定运行，上下文管理是关键。Agent TARS 的目标是打造一个能处理复杂、多轮任务的 Agent，尤其是在多模态场景（比如处理文本、图像、工具调用等）下，上下文可能会快速堆积，导致“内存溢出”。团队通过以下几个方面优化上下文管理： (1) 管理上下文窗口 LLM 的上下文窗口是有限的，比如常见的 128k token（大约是 128,000 个单词或字符片段）。在 Agent TARS 的运行中，每一轮任务都会生成新的上下文，包括用户的输入、Agent 的计划、工具调用结果等。如果不加优化，假设每次工具调用产生 5000 token 的数据，26 轮后上下文就会溢出。更别提多模态任务，比如处理一张高分辨率图片可能就占用 5000 token。 为了解决这个问题，Agent TARS 采用了动态滑动窗口策略，根据不同模态（文本、图像等）分别管理上下文，优化数据的使用效率。比如，图片数据和文本数据可以有不同的保留策略，确保关键信息不丢失，同时避免溢出。 (2) MCP 的挑战 MCP 是 Agent TARS 用来连接 Agent 和外部工具的机制，类似于一个工具分发的“中间件”。它让 Agent 开发者可以专注于 Agent 逻辑，而工具开发者提供标准化的工具接口。但在实践中，MCP 带来了一些问题： · 参数不一致：有些工具的参数格式不标准，可能导致模型无法正确调用 · 结果过大：某些工具（比如从网页抓取 HTML 的工具）返回的数据量太大，一次调用就可能让上下文溢出。例如，调用 `browser_get_html` 可能返回几十万 token 的网页数据，直接“炸”掉上下文窗口 为此，团队废弃了一些不高效的工具（比如 `browser_get_html`），转而使用更优的实现，比如基于 Readability 的 `browser_get_markdown`，通过分页等技术减少数据量。他们还得出一个结论：MCP 的真正价值在于**标准化的工具分发协议**，而不是让工具开发者随意注入复杂的上下文。未来，MCP 生态需要一个标准化的评估体系（Benchmark），来评判工具的质量，比如模型兼容性、上下文压缩效率等。 (3) 上下文压缩 为了进一步优化，Agent TARS 设计了多级记忆机制，将上下文分为四层： · L0（永久记忆）：跨任务保留，比如用户初始输入和 Agent 的最终回答 · L1（会话记忆）：仅在当前任务中有效，比如任务计划 · L2（循环记忆）：仅在当前任务循环中有效，比如工具调用结果、屏幕截图 · L3（临时记忆）：临时的流式数据，比如实时生成的消息片段 通过这种分层，Agent TARS 可以针对不同层级的上下文采取不同压缩策略，比如： · 选择性压缩：用智能算法减少不必要的消息内容 · 摘要生成：用大模型或小模型生成对话摘要，减少上下文体积 此外，团队还在计划支持 Responses API，利用图像缓存等技术进一步提升多模态任务的性能。 2. Observable and Evaluable（可观测与可评估） 核心理念：一个好的 Agent 框架需要让开发者清楚地看到 Agent 的运行过程（可观测），并能通过自动化测试评估其表现（可评估）。Agent TARS 在这方面做了两件事：Snapshot 机制和自动化评测。 (1) Snapshot 机制 Agent TARS 运行在一个复杂且多变的环境中，比如： · LLM 的输出随机性（同样的输入可能有不同回答） · 工具调用的不确定性（比如网络延迟或工具失败） · 环境初始化（比如启动浏览器或虚拟容器）的不稳定性 这些因素让 Agent 的运行状态难以追踪。为了解决这个问题，Agent TARS 引入了 Snapshot 机制，可以在运行时保存 Agent 的环境状态（包括上下文、工具调用、模型输出等），然后通过“回放”来重现 Agent 的行为。这有点像程序员调试代码时保存的“快照”，可以用来检查问题、确保稳定性。 Snapshot 机制已经用在了 Agent TARS 的持续集成（CI）中，帮助团队发现了 10 多个潜在 bug，显著提升了开发效率。 (2) 自动化评测 在 Alpha 版本中，Agent TARS 是一个 Electron 应用，只能靠人工测试，效率低下。Beta 版本引入了 Headless 模式，让自动化评测成为可能。团队参考了 OpenAI 的评测框架，开发了一个叫 browsecomp 的评测工具，可以通过 Python 和 TypeScript 跨进程调用，自动测试 Agent 的表现。 此外，他们还在构建针对 MCP 工具的评测集，专门测试工具在不同模型上的兼容性和性能。未来，这些评测工具会整合成一个完整的 Benchmark 方案，供社区使用。 3. Easy to Build Applications（易于构建应用） 核心理念：Agent TARS 要让开发者轻松构建自己的应用。为此，团队设计了 Agent Event Stream，一个基于事件流的机制，让 Agent 的运行过程可以被清晰地捕获和展示，方便开发者基于此构建 UI 或其他应用。 Agent Event Stream 是一个实时输出 Agent 运行状态的机制。比如，当你用 Agent TARS CLI 运行一个任务（比如查询“我的电脑型号”），你会看到一连串的事件流，包括： · Agent 的状态更新（比如“正在思考”） · 工具调用的细节（比如调用了 `getCurrentLocation` 工具） · 最终的回答（比如“你的电脑型号是 XXX”） 这些事件流可以被用来构建灵活的 UI。开发者只需要基于这些事件流，编写一个渲染器（Renderer），就能创建自定义的界面。比如，你可以用 Web 技术实现一个炫酷的 Agent TARS Web UI，也可以替换成自己的 UI 风格。 更厉害的是，Agent Event Stream 不仅用于 UI 渲染，还被用在 Context Engineering 中，帮助管理上下文（这点和前文提到的上下文工程无缝衔接）。这意味着，Agent TARS 的核心逻辑是围绕事件流构建的，开发者可以通过 SDK 轻松接入，感受这种设计的优雅。