Agent

Harness Engineering：OpenAI 智能体工程总结 [!abstract] 这篇文章真正讨论的重点，不是“AI 会不会写代码”，而是“怎样搭建一个让智能体持续稳定地产出代码、测试、文档与修复的工程系统”。 [!note] 这是一份基于原文的整理版总结，偏重方法论提炼，不是逐段直译。 标题怎么理解 Harness Engineering 如果直译并不自然。结合全文语境，我更倾向把它理解为： 面向智能体的工程编排 为智能体设计工作环境、约束和反馈回路的工程实践 也就是说，重点已经不只是“让模型写代码”，而是让它在一个可读、可测、可验证、可修复的系统里持续工作。 一句话总结 OpenAI 用一个很小的工程团队，在几个月内做出了一个已经有真实用户使用的内部产品；在这个过程中，人类几乎不直接写代码，而是把主要精力放在搭建代码仓库结构、文档体系、工具链、架构约束、可观测性和自动反馈回路上，让 Codex 能稳定地产生、验证、修复并合并变更。 文章的核心信息 1. 人类从“写代码”转向“设计系统” 文章里最关键的一句话可以概括为：人类掌舵，智能体执行。 工程师的主要职责不再是亲手补实现，而是： 把目标拆成智能体能完成的任务 提供足够清晰的上下文和约束 设计反馈回路，让智能体自己发现问题并修复 当智能体做不好一件事时，重点不是“再提示一次”，而是追问：是不是缺工具、缺文档、缺规则、缺可观察性。 2. AGENTS.md 应该是地图，不该是百科全书 他们早期试过写一个超大的 AGENTS.md，结果失败了。原因很直接： 上下文窗口是稀缺资源 规则太多以后，模型会丢失重点 大而全的说明很快就会过期 单文件很难机械检查和持续维护 所以更好的做法是： 用简短的 AGENTS.md 充当导航地图 把真正的知识沉淀到结构化的 docs/ 中 给设计文档、执行计划、产品规格、架构说明和质量评分做索引 这本质上是在做渐进式披露：先给入口，再按需深入，而不是一次性把所有东西塞给模型。 3. 代码仓库要成为唯一可信的记录系统 对智能体来说，拿不到上下文就等于不存在。 所以那些只存在于聊天记录、口头讨论、Google Docs 或人脑里的决策，实际上都无法被智能体可靠地复用。文章强调，应该把越来越多的重要上下文沉淀回仓库，包括： 架构原则 产品约束 设计决策 执行计划 技术债状态 代码质量标准 这样智能体才能基于版本化的、可检索的材料持续工作。 4. 不只是代码要可读，应用本身也要对智能体可读 他们做了很多“让智能体自己看得见系统状态”的建设，比如： 支持基于 git worktree 启动独立应用实例 把浏览器调试能力接入智能体运行时 提供 DOM 快照、截图、导航等能力 把日志、指标、链路追踪也暴露给智能体查询 这样智能体就不只是“改代码”，还可以： ...

上下文管理 [!summary] 这一章真正想回答的问题是：每次调用大模型前，怎样把最有用的信息组织好再交给模型？ 所谓上下文工程，不是单纯研究提示词，而是研究如何把任务目标、规则、状态、记忆、检索结果和工具输出组织成一次高质量输入。 1. 这一章到底在讲什么 上下文工程（Context Engineering）的核心不是“给模型更多信息”，而是“给模型更合适的信息”。它关注的是： 哪些信息应该进入这次调用的上下文 这些信息应该按什么顺序和结构摆放 信息太长时该如何压缩与取舍 这件事之所以重要，是因为在真实 Agent 场景里，仅有 [[智能体基础#大语言模型基础（智能体的大脑）|模型能力]]、记忆系统或 RAG 还不够。系统仍然需要持续、系统地构造恰当上下文，否则模型容易答偏、忘重点，或者浪费大量 token。 [1] 2. 一句最容易记住的话 [!note] 上下文工程不是“喂更多信息”，而是“喂更合适的信息”。 这几个概念最好分开记： Prompt Engineering：关注提示词怎么写 RAG：关注去哪里找外部知识 Context Engineering：关注怎样把目标、规则、历史状态、检索结果、记忆和工具返回整体装配成一次高质量输入 [1] 3. 为什么上下文工程重要 3.1 真实任务不是一次性问答 Agent 往往需要持续交互、调用工具、读文件、做判断。此时模型看到的不只是“用户当前一句话”，还包括： 历史动作 中间结论 系统规则 当前任务状态 外部工具的返回结果 [1] 3.2 上下文窗口不是越大越好 上下文变长，并不意味着模型会自动抓重点。信息过多时，反而可能出现： 重点被埋没 注意力分散 无关噪声干扰推理 所以关键不是“全塞进去”，而是“筛选后再组织”。 [1] 3.3 长程任务必须做状态管理 做代码维护、研究任务、长对话助手时，如果没有中间笔记、结构化状态和压缩机制，模型很容易在长流程中忘掉前面的关键事实。这也是本章引入 NoteTool 和 TerminalTool 的直接原因。 [1] 4. 这章最重要的框架：GSSC Hello-Agents 把上下文构建总结成一个四步流水线： GSSC = Gather -> Select -> Structure -> Compress [2] ...

Agent 开发 [!summary] 本文把“智能体经典范式（怎么思考与执行）”和“框架开发实践（怎么工程化落地）”合并为一份速记。 第一部分：三大经典范式 下面按《第四章 智能体经典范式构建》里提到的三种智能体模式做一个抓重点总结：ReAct、Plan-and-Solve、Reflection。 ([GitHub][1]) 1) ReAct（Reasoning and Acting） 核心思想：把 Thought、Action、Observation 放进同一闭环，边推理边行动，利用外部反馈持续修正。 ([GitHub][2]) 典型流程： Thought：分析现状、决定下一步 Action：调用工具或输出最终答案 Observation：读取工具结果并更新上下文 循环直到完成或达到步数上限 优势： 可解释性强 动态纠错快 特别适合工具驱动任务（搜索/计算/API） 局限： 依赖模型格式遵循与推理稳定性 多轮调用带来时延与成本 提示词和解析链条较脆弱 2) Plan-and-Solve 核心思想：先规划（Plan）再执行（Solve），通过“先出蓝图”提升执行稳定性。 ([GitHub][1]) 典型流程： Planning：分解任务并输出步骤计划 Solving：按计划逐步执行，前一步结果作为后续上下文 优势： 结构清晰、目标一致性高 适合路径确定、内部推理密集任务 局限： 计划偏静态，执行中遇到新情况需要额外动态重规划机制 3) Reflection 核心思想：执行后反思、反思后修订，通过迭代提升质量与可靠性。 ([GitHub][1]) 典型流程： Execution：先生成初稿 Reflection：从评审视角给结构化反馈 Refinement：基于初稿与反馈生成改进版 多轮迭代直到收敛或到上限 优势： 显著提升代码/方案类输出的可用性与正确性 关键配套： 需要记忆/轨迹存储，保留每轮执行与反馈支撑持续优化 三者怎么选 ReAct：信息不全且要边探索边调用工具 Plan-and-Solve：路径较确定且要稳定多步执行 Reflection：质量优先且接受更高迭代成本 第二部分：四大框架实践 1. 为什么从手写走向框架 复用与效率：封装通用循环，减少重复造轮子 解耦与扩展：模型/工具/记忆分层，替换更容易 状态管理：支持长时运行与多轮状态追踪 可观测调试：回调与钩子提升排障效率 2. 四个代表框架抓重点 2.1 AutoGen（对话协作优先） 核心理念：多智能体协作抽象为自动群聊 关键机制：autogen-core + autogen-agentchat、异步优先、角色分工（AssistantAgent / UserProxyAgent） 案例：软件团队协作做实时比特币价格 Web 应用 2.2 AgentScope（工程化优先） 核心理念：面向企业级生产，强调分布式、容错、可观测 关键机制：消息驱动 + 组合式架构，并发执行、状态管理、工具并行 案例：三国狼人杀，突出结构化约束、并发投票、异常兜底 2.3 CAMEL（轻量角色扮演） 核心理念：用最少人工编排驱动角色协作 关键机制：Role-Playing + Inception Prompting 案例：AI 心理学家 + AI 作家协作写拖延症科普电子书 2.4 LangGraph（图状态机工作流） 核心理念：把流程建模为状态机有向图 关键机制：Nodes + Edges + 全局 State 案例：三步问答助手、条件路由循环（add_conditional_edges） 权衡：流程可控性强，但设计与调试复杂度更高 3. 一页选型速查 框架 最适合场景 主要优势 主要代价 AutoGen 多角色对话协作 协作自然、上手快 成本与流程稳态约束压力 AgentScope 企业级并发与分布式 工程化能力强 接入与学习成本更高 CAMEL 轻量实验与创作协作 机制简洁、验证快 对提示依赖高 LangGraph 强流程控制与循环任务 状态显式、可控性强 样板与调试复杂度高 总结 范式决定“思考与行动方式”。 框架决定“工程落地能力”。 实战里通常是组合使用：先选范式，再用合适框架把范式稳定实现。 参考 [1] hello-agents/docs/chapter4/第四章 智能体经典范式构建.md [2] chapter4 原始 markdown [3] 第六章 框架开发实践 | Hello-Agents

智能体基础 [!note] 定义 智能体（Agent）是能够感知环境、进行推理并执行动作以达成目标的系统。 三个核心要素 目标（Goal）：要解决什么问题。 记忆（Memory）：保存上下文与历史决策。 工具（Tools）：调用外部能力执行任务。 一个最小工作流 接收任务 拆解步骤 执行与验证 输出结果并记录经验 智能体分类 [!summary] 智能体的分类可以从两条主线理解： 传统演进路线（从规则反应到学习进化） 三个现代互补维度（决策架构、时间反应性、知识表示） 一、传统演进视角 简单反射智能体（Simple Reflex Agent） 仅依赖当前感知输入。 基于预设的“条件-动作”规则。 无记忆、无预测能力。 基于模型的反射智能体（Model-Based Reflex Agent） 引入内部世界模型（World Model）。 能追踪不可直接观测的环境状态。 具备初级记忆能力。 基于目标的智能体（Goal-Based Agent） 从“被动反应”转向“主动达成目标”。 会进行规划（Planning）并评估行动路径。 基于效用的智能体（Utility-Based Agent） 在多目标冲突下进行权衡。 为状态赋予效用值，追求期望效用最大化。 学习型智能体（Learning Agent） 包含性能元件与学习元件。 通过与环境交互持续自我修正（如强化学习）。 可从“依赖规则”演进为“依赖经验”。 二、现代三大分类维度 1. 基于内部决策架构 关注“内部决策机制复杂度”的层级。 基本覆盖从简单反应式到效用决策式的阶梯。 学习能力可视为可叠加在各类架构上的元能力。 2. 基于时间与反应性 反应式智能体（Reactive Agents） 感知到行动的直接映射。 优点：速度快、计算开销低。 局限：缺乏长程规划，易陷入局部最优。 规划式/审议式智能体（Deliberative Agents） 行动前基于世界模型进行推演。 优点：战略性强、可评估长期后果。 局限：时间和计算成本较高。 混合式智能体（Hybrid Agents） 结合反应式与规划式优势。 兼顾即时响应与长期目标。 典型例子：LLM 智能体在“思考-行动-观察”循环中运作。 3. 基于知识表示 符号主义 AI（Symbolic AI） ...