斎藤龍太郎

斎藤龍太郎

くらっち

L ψ η Λ r I🌙

Inogic Powers #Copilot in #Dynamics365 #PowerApps

WindowsForum

brainlag

su

サナエトweb3

Jean Chen 🦞 | ⬅️ AI · Crypto ➡️

Jean Chen 🦞 | ⬅️ AI · Crypto ➡️

@cryptojean27

Apr 19

Agent Harness 架构解剖深度剖析 Anthropic、OpenAI、Perplexity 和 LangChain 正在构建的底层架构。涵盖编排循环、工具、记忆、上下文管理，以及将无状态 LLM 转化为能干 Agent 的一切核心要素。你搭过聊天机器人。也许你用几个工具跑通了一个 ReAct 循环。Demo 演示没问题。然后你尝试构建一个生产级系统，轮子就掉了：模型忘记三步之前做了什么，工具调用静默失败，上下文窗口被垃圾填满。问题不在你的模型。问题在模型周围的一切。 LangChain 已经证明了这一点——他们只更换了包裹 LLM 的基础设施（同一个模型、同样的权重），就在 TerminalBench 2.0 上从前30名开外跃升到第5名。另一个独立研究项目让 LLM 自行优化基础设施，达到了76.4%的通过率，超越了人工设计的系统。这套基础设施现在有了一个名字：Agent Harness（智能体线束/框架）。什么是 Agent Harness？这个术语在 2026 年初被正式确立，但概念早已存在。Harness 是包裹 LLM 的完整软件基础设施：编排循环、工具、记忆、上下文管理、状态持久化、错误处理和安全护栏。Anthropic 的 Claude Code 文档简明地表述道：SDK 就是"驱动 Claude Code 的 Agent Harness"。OpenAI 的 Codex 团队使用同样的框架，明确地将"Agent"和"Harness"视为等价术语，指代使 LLM 真正有用的非模型基础设施。我非常喜欢 LangChain 的 Vivek Trivedy 给出的经典公式："如果你不是模型，你就是 Harness。" 这里有一个容易让人混淆的区分。"Agent"是涌现行为：用户交互的那个有目标导向、会使用工具、能自我纠正的实体。Harness 是产生这种行为的机器。当有人说"我构建了一个 Agent"，他们的意思是构建了一个 Harness 并将其指向一个模型。 Beren Millidge 在他2023年的文章《作为自然语言计算机的脚手架 LLM》中精确地阐述了这个类比。一个原始 LLM 就是一个没有 RAM、没有磁盘、没有 I/O 的 CPU。上下文窗口充当 RAM（快但有限）。外部数据库充当磁盘存储（大但慢）。工具集成充当设备驱动。Harness 就是操作系统。正如 Millidge 所写："我们重新发明了冯·诺依曼架构"——因为这是任何计算系统的自然抽象。三个层次的工程围绕模型存在三个同心层次的工程： 1. 提示工程（Prompt Engineering）：精心设计模型接收的指令。 2, 上下文工程（Context Engineering）：管理模型看到什么以及何时看到。 3. Harness 工程（Harness Engineering）：涵盖前两者，加上整个应用基础设施：工具编排、状态持久化、错误恢复、验证循环、安全执行和生命周期管理。 Harness 不是对提示的包装。它是使自主 Agent 行为成为可能的完整系统。生产级 Harness 的12个组件综合 Anthropic、OpenAI、LangChain 以及更广泛的实践者社区，一个生产级 Agent Harness 有十二个独立组件。逐一拆解如下。 1. 编排循环（The Orchestration Loop）这是心跳。它实现了思考-行动-观察（TAO）循环，也叫 ReAct 循环。循环运行：组装提示 → 调用 LLM → 解析输出 → 执行工具调用 → 将结果反馈回去 → 重复直到完成。机制上，它通常只是一个 while 循环。复杂性在于循环所管理的一切，而非循环本身。Anthropic 将他们的运行时描述为一个"傻循环"——所有智能都在模型中。Harness 只管理轮次。 2. 工具（Tools）工具是 Agent 的双手。它们被定义为 schema（名称、描述、参数类型），注入到 LLM 的上下文中，让模型知道有什么可用。工具层处理注册、schema 校验、参数提取、沙箱执行、结果捕获，以及将结果格式化为 LLM 可读的观察结果。 Claude Code 提供六类工具：文件操作、搜索、执行、网络访问、代码智能和子 Agent 生成。OpenAI 的 Agents SDK 支持函数工具（通过 @function_tool）、托管工具（WebSearch、CodeInterpreter、FileSearch）和 MCP 服务器工具。 3. 记忆（Memory）记忆在多个时间尺度上运作。短期记忆是单次会话内的对话历史。长期记忆跨会话持久化：Anthropic 使用 CLAUDE.md 项目文件和自动生成的 MEMORY.md 文件；LangGraph 使用命名空间组织的 JSON Store；OpenAI 支持由 SQLite 或 Redis 支撑的 Sessions。 Claude Code 实现了三级层次结构：轻量级索引（每条约150字符，始终加载）、按需拉取的详细主题文件、以及仅通过搜索访问的原始记录。一个关键设计原则：Agent 将自己的记忆视为"提示"，在行动前根据实际状态进行验证。 4. 上下文管理（Context Management）这是许多 Agent 静默失败的地方。核心问题是上下文腐烂（context rot）：当关键内容落在窗口中部位置时，模型性能下降30%以上（Chroma 研究，得到斯坦福"Lost in the Middle"发现的印证）。即使百万 token 的窗口，随着上下文增长也会出现指令遵循能力退化。生产级策略包括： - 压缩（Compaction）：在接近限制时总结对话历史（Claude Code 保留架构决策和未解决的 bug，同时丢弃冗余的工具输出） - 观察遮蔽（Observation Masking）：JetBrains 的 Junie 隐藏旧的工具输出，同时保持工具调用可见 - 即时检索（Just-in-time Retrieval）：维护轻量级标识符，动态加载数据（Claude Code 使用 grep、glob、head、tail 而非加载完整文件） - 子 Agent 委派（Sub-agent Delegation）：每个子 Agent 广泛探索，但只返回1,000到2,000 token 的精炼摘要 Anthropic 的上下文工程指南阐明了目标：找到最小的高信号 token 集合，最大化期望结果的可能性。 5. 提示构建（Prompt Construction）这决定了模型在每一步实际看到什么。它是分层的：系统提示 → 工具定义 → 记忆文件 → 对话历史 → 当前用户消息。 OpenAI 的 Codex 使用严格的优先级栈：服务器控制的系统消息（最高优先级）→ 工具定义 → 开发者指令 → 用户指令（级联的 AGENTS.md 文件，32 KiB 限制）→ 对话历史。 6. 输出解析（Output Parsing）现代 Harness 依赖原生工具调用，即模型返回结构化的 tool_calls 对象而非需要解析的自由文本。Harness 检查：有工具调用吗？执行并继续循环。没有工具调用？那就是最终答案。对于结构化输出，OpenAI 和 LangChain 都支持通过 Pydantic 模型进行 schema 约束响应。传统方法如 RetryWithErrorOutputParser（将原始提示、失败的补全和解析错误一起反馈给模型）仍适用于边缘情况。 7. 状态管理（State Management） LangGraph 将状态建模为流经图节点的类型化字典，使用 reducer 合并更新。检查点在超步骤边界处发生，支持中断后恢复和时间旅行调试。OpenAI 提供四种互斥策略：应用记忆、SDK 会话、服务端 Conversations API，或轻量级 previous_response_id 链接。Claude Code 采用不同的方法：git commit 作为检查点，进度文件作为结构化草稿本。 8. 错误处理（Error Handling）为什么这很重要：一个10步流程如果每步99%的成功率，端到端成功率只有约90.4%。错误以复利方式累积。 LangGraph 区分四种错误类型：瞬时性（带退避重试）、LLM 可恢复（将错误作为 ToolMessage 返回让模型调整）、用户可修复（中断请求人工输入）、意外错误（向上冒泡用于调试）。Anthropic 在工具处理器内捕获失败并将其作为错误结果返回，以保持循环运行。Stripe 的生产 Harness 将重试次数上限设为两次。 9. 安全护栏（Guardrails and Safety） OpenAI 的 SDK 实现三个级别：输入护栏（在首个 Agent 上运行）、输出护栏（在最终输出上运行）、工具护栏（在每次工具调用时运行）。"绊线"（tripwire）机制在触发时立即停止 Agent。 Anthropic 在架构层面将权限执行与模型推理分离。模型决定尝试什么；工具系统决定允许什么。Claude Code 独立管控约40个离散的工具能力，分三个阶段：项目加载时建立信任、每次工具调用前权限检查、高风险操作需用户明确确认。 10. 验证循环（Verification Loops）这是玩具 Demo 和生产级 Agent 的分水岭。 Anthropic 推荐三种方法：基于规则的反馈（测试、linter、类型检查器）、视觉反馈（通过 Playwright 截图用于 UI 任务）、LLM 作为评判者（单独的子 Agent 评估输出）。 Claude Code 的创造者 Boris Cherny 指出，给模型一种验证自己工作的方式能将质量提升2到3倍。 11. 子 Agent 编排（Subagent Orchestration） Claude Code 支持三种执行模式： - Fork：父上下文的字节级精确副本 - Teammate：独立终端面板，通过文件系统邮箱通信 - Worktree：独立的 git worktree，每个 Agent 一个隔离分支 OpenAI 的 SDK 支持 Agent 作为工具（专家处理有界子任务）和 Handoff（专家接管全部控制）。LangGraph 将子 Agent 实现为嵌套的状态图。循环运作：逐步追踪现在你了解了组件，让我们追踪它们如何在一个完整周期中协同工作。步骤1（提示组装）：Harness 构建完整输入：系统提示工具 schema 记忆文件对话历史当前用户消息。重要上下文被放置在提示的开头和结尾（"Lost in the Middle"发现）。步骤2（LLM 推理）：组装好的提示发送到模型 API。模型生成输出 token：文本、工具调用请求，或两者兼有。步骤3（输出分类）：如果模型生成了纯文本没有工具调用，循环结束。如果请求了工具调用，进入执行。如果请求了 Handoff，更新当前 Agent 并重新开始。步骤4（工具执行）：对于每个工具调用，Harness 验证参数、检查权限、在沙箱环境中执行、捕获结果。只读操作可以并发；写操作串行执行。步骤5（结果打包）：工具结果被格式化为 LLM 可读的消息。错误被捕获并作为错误结果返回，让模型能够自我纠正。步骤6（上下文更新）：结果追加到对话历史。如果接近上下文窗口限制，Harness 触发压缩。步骤7（循环）：返回步骤1。重复直到终止。终止条件是分层的：模型生成了无工具调用的响应、超过最大轮次限制、token 预算耗尽、安全护栏绊线触发、用户中断、或返回安全拒绝。一个简单问题可能需要1到2轮。一个复杂的重构任务可以跨越数十次工具调用。对于跨越多个上下文窗口的长时间运行任务，Anthropic 开发了两阶段的 "Ralph Loop"模式：初始化 Agent 设置环境（初始化脚本、进度文件、功能列表、初始 git commit），然后编码 Agent 在后续每个会话中读取 git 日志和进度文件来定位自己，选择最高优先级的未完成功能，处理它，提交，并写入摘要。文件系统提供了跨上下文窗口的连续性。真实框架如何实现这一模式 Anthropic 的 Claude Agent SDK 通过单个 query() 函数暴露 Harness，创建 Agent 循环并返回异步迭代器流式传输消息。运行时是一个"傻循环"——所有智能都在模型中。Claude Code 使用收集-行动-验证（Gather-Act-Verify）循环：收集上下文（搜索文件、阅读代码）→ 采取行动（编辑文件、运行命令）→ 验证结果（运行测试、检查输出）→ 重复。 OpenAI 的 Agents SDK 通过 Runner 类实现 Harness，有三种模式：异步、同步和流式。SDK 是"代码优先"的：工作流逻辑用原生 Python 表达，而非图 DSL。Codex Harness 在此基础上扩展为三层架构：Codex Core（Agent 代码运行时）、App Server（双向 JSON-RPC API）和客户端表面（CLI、VS Code、Web 应用）。所有表面共享同一个 Harness，这就是为什么"Codex 模型在 Codex 界面上的表现比通用聊天窗口好"。 LangGraph 将 Harness 建模为显式的状态图。两个节点（llm_call 和 tool_node）通过条件边连接：如果存在工具调用，路由到 tool_node；如果不存在，路由到 END。LangGraph 从 LangChain 的 AgentExecutor 演化而来，后者在 v0.2 中被弃用，因为它难以扩展且缺乏多 Agent 支持。LangChain 的 Deep Agents 明确使用"Agent Harness"一词：内置工具、规划（write_todos 工具）、用于上下文管理的文件系统、子 Agent 生成和持久记忆。 CrewAI 实现了基于角色的多 Agent 架构：Agent（围绕 LLM 的 Harness，由角色、目标、背景故事和工具定义）、Task（工作单元）、Crew（Agent 集合）。CrewAI 的 Flows 层增加了"在关键处注入智能的确定性骨架"，管理路由和验证，同时 Crew 处理自主协作。 AutoGen（正演化为 Microsoft Agent Framework）开创了对话驱动的编排。其三层架构（Core、AgentChat、Extensions）支持五种编排模式：顺序、并发（扇出/扇入）、群聊、Handoff 和 Magentic（管理 Agent 维护动态任务账本协调专家）。脚手架隐喻脚手架隐喻不是装饰性的。它是精确的。建筑脚手架是临时基础设施，让工人能够建造他们否则无法够到的结构。它不执行建设工作，但没有它，工人无法到达高层。关键洞察：脚手架在建筑完成后被拆除。随着模型能力提升，Harness 复杂性应当降低。Manus 在六个月内重构了五次，每次重写都在移除复杂性。复杂的工具定义变成了通用的 shell 执行。"管理 Agent"变成了简单的结构化 Handoff。这指向了共同演化原则：模型现在在训练后阶段已经将特定 Harness 纳入循环。Claude Code 的模型学习了使用它所训练的特定 Harness。更改工具实现可能会降低性能，因为这种紧耦合关系。 Harness 设计的"面向未来测试"：如果性能随着更强大的模型提升而无需增加 Harness 复杂性，那么设计就是合理的。定义每个 Harness 的七个决策每个 Harness 架构师都面临七个选择： 1. 单 Agent vs. 多 Agent Anthropic 和 OpenAI 都说：先最大化单个 Agent 的能力。多 Agent 系统增加开销（路由需要额外的 LLM 调用、Handoff 过程中丢失上下文）。只有当工具过载超过约10个重叠工具，或存在明显独立的任务领域时才拆分。 2. ReAct vs. 先规划后执行 ReAct 在每一步都交织推理和行动（灵活但每步成本更高）。先规划后执行将规划与执行分离。LLMCompiler 报告比顺序 ReAct 快3.6倍。 3. 上下文窗口管理策略五种生产级方法：基于时间清除、对话摘要、观察遮蔽、结构化笔记、子 Agent 委派。ACON 研究显示在保持95%以上准确率的同时减少26到54%的 token 消耗，方法是优先保留推理轨迹而非原始工具输出。 4. 验证循环设计计算性验证（测试、linter）提供确定性的事实依据。推理性验证（LLM 作为评判者）能捕获语义问题但增加延迟。Martin Fowler 的 Thoughtworks 团队将此框架化为引导器（前馈，行动前引导）与传感器（反馈，行动后观察）。 5. 权限和安全架构宽松模式（快但有风险，自动批准大多数操作）vs. 严格模式（安全但慢，每个操作都需要批准）。选择取决于部署场景。 6. 工具范围策略更多工具往往意味着更差的性能。Vercel 从 v0 中移除了80%的工具，获得了更好的结果。Claude Code 通过懒加载实现了95%的上下文减少。原则：只暴露当前步骤所需的最小工具集。 7. Harness 厚度多少逻辑放在 Harness 中 vs. 模型中。Anthropic 押注薄 Harness 和模型改进。基于图的框架押注显式控制。Anthropic 定期从 Claude Code 的 Harness 中删除规划步骤，因为新版本模型已经将该能力内化。 Harness 即产品使用相同模型的两个产品，仅凭 Harness 设计的不同就能产生截然不同的性能。TerminalBench 的证据很清楚：仅更换 Harness 就让 Agent 的排名跳升了20多个位次。 Harness 既不是已解决的问题，也不是商品层。它是最硬核工程所在之处：将上下文作为稀缺资源来管理、设计在错误级联之前捕获失败的验证循环、构建提供连续性而不产生幻觉的记忆系统、以及在构建多少脚手架与留多少给模型之间做出架构押注。这个领域正在向更薄的 Harness 演进。但 Harness 本身不会消失。即使是最强大的模型也需要某个东西来管理它的上下文窗口、执行它的工具调用、持久化它的状态、并验证它的工作。下次你的 Agent 失败时，不要怪模型。看看 Harness。

Akshay 🚀

@akshay_pachaar

Apr 6

x.com/i/article/204073208484…

2,511

【AWS】Bedrock AgentCoreを使ってAIにPythonによるデータ分析ができるCode Interpreterを使わせてみる！ - Qiita

SignalFuse — Trading Intelligence for AI Agents

Release v3.2.2 Sandbox Security and Code Interpreter Architecture · haseeb-heaven/code-interpreter

Release v3.2.1 · haseeb-heaven/code-interpreter