跳到主要内容

上下文工程与能力上限

上下文工程是什么，为什么它决定 Agent 的上限？​

  • 定义: 上下文工程（Context Engineering）是对 Agent 每次实际看到的全部信息进行设计与管理;
  • 范围: 对话历史、系统指令、工具描述、外部知识，而不只是往提示词里多塞内容;
  • 定位: 是 Harness 工程 中“上下文与工具”层面的核心实现，决定 Agent 在每个决策点看到什么、以什么结构看到;
  • 比喻: 天才工程师加入团队却不知产品架构、业务逻辑与技术债，智力再高也难发挥作用;
  • 结论: 一个中等能力的模型配上精心组织的上下文，往往胜过一个顶级模型在信息匮乏下的盲目摸索;
  • 本质: 系统性设计并组织模型完成任务所需的全部背景知识，使通用能力在具体任务中得以释放;

Agent 有效工作的最低信息需求有哪三类？​

  • 实时代码上下文: 目录结构、模块职责、核心数据结构、代码规范;
  • 流程规范: Git 分支策略、提交规范、代码审查流程、CI/CD 要求;
  • 环境信息: 开发环境配置、测试数据库地址、测试环境部署方式、API 密钥管理;
  • 边界: 进入上下文的是对环境的观察、描述或配置，Environment 仍是与 Agent 交互的外部对象（见 观察与动作空间）;
  • 后果: 缺代码规范则写出与项目格格不入的代码；缺流程规范则可能向主分支提交未测试代码；缺环境信息则本地跑通的修复在测试环境崩溃;

为什么上下文工程同时是一个组织问题？​

  • 隐性知识: 架构决策只在老员工记忆里、业务规则靠口口相传、背景信息锁在私聊记录中;
  • 判断: 团队本身是信息黑洞时，再好的 Agent 也无计可施;
  • 相关规律: 对远程工作友好的团队往往也对 AI Agent 友好;
  • 范例: Linux 内核项目几十年透明、文档驱动——讨论公开、决策有记录、新人可读历史理解演化;
  • 行动: 构建 AI 原生团队首先是一场文档化运动，而不只是部署新工具;
  • 引述: 翁家翌——“人和模型一样，最重要的是 Context”；“团队合作中最大的问题也是 context 的不一致”;
  • 类比: AI Agent 像一个永远的新员工，给足背景信息能干得很好，什么都不告诉它再聪明也白搭;

ReAct 如何形式化 Agent 的上下文？​

  • 公式: 时刻 tt 的 Agent 依策略 π(at∣ct)\pi(a_t \mid c_t) 从环境观察 ot∈Oo_t \in \mathcal{O} 采取动作 at∈Aa_t \in \mathcal{A};
  • 上下文: ct=(o1,a1,…,ot−1,at−1,ot)c_t=(o_1,a_1,\ldots,o_{t-1},a_{t-1},o_t)，即截至当前的完整交互历史;
  • 关键: 下一步行动取决于完整交互上下文，而不只是眼前这一条输入;
  • 映射: 用户消息与工具执行结果属于观察，模型回复与工具调用请求属于行动;
  • 无状态约束: 模型 API 无状态，每次调用都必须由 Agent 框架重新构造足够的上下文;
  • 核心问题: 后文所有上下文布局、状态栏与压缩技术都在回答同一件事——怎样以更低成本提供信息充分的 ctc_t;
  • 基准做法: 最直接无损的是带上完整消息历史；生产系统可摘要压缩，但不能悄悄丢掉决定下一步行动所需的信息;