两家公司给自己的 AI Agent 分别推出了 Chrome 扩展。表面上都是"让 AI 能操作浏览器"，但出发点几乎相反：Claude in Chrome 是把 AI 嵌进浏览器里，Codex Chrome 扩展是把浏览器接进 AI 任务系统里。 产品定位 Claude in Chrome 是 claude.ai 的浏览器扩展，主要形态是侧边栏。浏览时 Claude 在旁边响应，可以读当前页面、执行操作、或者后台跑多步骤工作流。也对接了 Claude Desktop，可以在桌面端控制浏览器。
Claude Code 现在支持 Artifacts —— 一句话版：你让 Claude Code 干活时，它可以把过程和结果生成一个可交互的网页，分享给团队看，而且会随着 Claude Code 继续工作自动更新。 Artifact 是什么 以前 Claude Code 的工作成果散在终端输出和对话里。查完 bug、读完代码、推理出根因之后，要把这些东西传递给其他人，只能截图、复制粘贴、或者口头转述。Claude Code 的 Artifacts 把这些工作打包成一个可访问的网页。
默认状态下，Claude Code 在完成一个任务后就停下来等待 —— 即每轮结束后，将控制权还给我们，由我们决定下一步。这种交互方式对大多数任务足够，但某些工作需要 Claude 跨越多轮自主运行：修复一批测试直到全部通过、定期检查部署状态、对整个代码库做并行扫描。这时候需要的不是更多的手动催促，而是一套合适的驱动机制。
Codex 已经不只是一个待在终端和编辑器里的编程助手了。它现在可以通过不同的 surface 接触外部环境。这里的 surface 可以理解为 Codex 操作电脑和网页的入口，目前最容易混在一起的三种是：@Computer、@Chrome 和 @Browser。 它们看起来都和“用电脑”“打开浏览器”有关，实际边界却差得很远。选错入口，体验会立刻变差：需要登录态的后台任务，如果交给隔离的内置 Browser，它拿不到你的账号、Cookie 和浏览器扩展；只是看一个本地 localhost 页面，如果让 Computer Use 去打开真实浏览器一步步操作，就会把简单的页面验证变成慢点要死的慢动作。
今天 Google Cloud 发布了 Open Knowledge Format（OKF），一个把 LLM Wiki 模式标准化的开放规范。读完之后感觉这件事比标题看起来重要得多——它触碰的是构建 AI Agent 时一个真正的基础性问题。 问题：上下文组装是一个重复造轮子的苦差事 基础模型越来越强，但限制它们能做什么的往往不是模型能力，而是相关上下文的缺失。当一个 Agent 需要回答"怎么从我们的事件流里算 weekly active users？“时，它得从以下地方拼凑答案：
当我们谈论如何用好 AI 编程时，大多数人还停留在"如何写出更好的 Prompt"这个层面。但真正的范式转移正在发生：与其继续手写 Prompt 指挥 Agent，不如设计一个能自动驱动 Agent 的"小系统"。这就是循环工程（Loop Engineering）。
原文: Building effective agents, 作者: Anthropic, Dec 20, 2024 https://www.anthropic.com/research/building-effective-agents 过去一年，我们与数十个团队合作，构建了跨行业的大型语言模型(LLM)智能体。我们发现，最成功的实现并没有使用复杂的框架或专门的库，而是使用简单、可组合的模式构建的。 在这篇文章中，我们将分享我们与客户合作以及自行构建智能体的经验，并为开发人员提供构建有效智能体的实用建议。
1.OPENAI Assistants API概述 OPENAI Assistants API概述:构建AI助手，并提供工具和集成功能 OPENAI的Assistants API允许我们在自己的应用程序中构建AI助手。助手包含指令(instructions)，并可以利用模型(models)、工具(tools)和文件(files)来响应用户查询。Assistants API 当前支持三种类型的工具：代码解释器、文件搜索和函数调用。
智能体(AI Agent)不仅仅是一个简单的程序，它能够通过与环境的互动，完成复杂的任务。而其中，大型语言模型（LLM）在智能体中的应用，十分重要。 什么是智能体? 智能体/Agent/代理 简单来说，智能体可以看作是一个能够理解命令、执行任务并与环境互动的“代理”。它不仅能够接受指令，还能根据自身的目标和环境情况，决定采取什么行动。