Context Engineering目标管理整个上下文状态系统指令、工具、模型上下文协议MCP、外部数据、消息历史记录等的策略与Prompt engineering的比较常用上下文调用范式长上下文常见问题语境中毒当幻觉进入语境时https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html?refblog.langchain.com#context-poisoning情境干扰当情境压倒训练时https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html?refblog.langchain.com#context-distraction语境混淆当多余的语境影响反应时https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html?refblog.langchain.com#context-confusion语境冲突当语境的不同部分不一致时https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html?refblog.langchain.com#context-clash总目标解决“上下文腐烂”问题其根源是Transformer架构的Attention机制。解决方法基础上下文组件System prompts将提示组织成不同的部分例如background_information等 并使用XML标记或Markdown 标题等技术来区分这些部分力求使用最少的信息完整地描述预期行为最少并不一定意味着简短最好先使用最佳模型测试一个最少的提示看看它在您的任务上的表现如何然后根据初始测试中发现的故障模式添加清晰的说明和示例来改进性能。Tools为Agent精心挑选一套最小可行工具集,避免臃肿和工具调用故障Few-shot example少样本提示努力精心挑选一组多样化的、规范的示例而非极端示例运行时上下文检索策略基于 embedding 预先检索相关内容使用Web searcher即时构建上下文Agent自主地导航和检索数据,通过探索逐步发现相关的上下文长期任务专用技术Compaction临近上下文窗口上限时对话历史进行摘要总结重置上下文摘要递归摘要或分层摘要特定节点添加摘要对某些工具调用例如词元密集型搜索工具进行后处理。再举一个例子Cognition提到在智能体之间的边界处添加摘要功能以减少知识交接过程中的词元数量。上下文修剪Drew 提出的剪枝包括硬编码方法、Provence针对问答的上下文修剪器结构化笔记/Agent记忆将关键信息持久化到外部存储后续按需拉回编写上下文:scratchpads:当前会话/线程内Anthropic研究员首先会仔细思考研究方法并将计划保存到内存中以保留上下文; **Memories:**跨多个会话记住信息选择上下文*scratchpads:**和工具调用结合/选择性暴露Agent运行时状态;**Memories:**情景记忆-给可供模仿的范例、程序性记忆-引导行为、语义记忆-提供任务相关背景事实langchainSub-agent:主Agent协调多专业Sub-Agent分担任务各自返回精简摘要 i.隔离语境-Multi-Agent: OpenAI Swarm库 ii.环境隔离工具调用API\Code Agent类似沙箱 iii.隔离Agent运行时的状态对象如只有messages在每回合中显示暴露但隔离其它字段参考文献https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agentshttps://www.langchain.com/blog/context-engineering-for-agentsHarness Engineering概念起源OpenAI 在 2026 年 2 月提出的工程范式工程师不写代码而是设计环境、明确意图、构建反馈回路Ralph Loop让 AI 智能体可靠地完成工作。Ralph Loop:一个革命性的 AI 编码框架其灵感来源于《辛普森一家》中的角色 Ralph Wiggum 他以迷糊但坚持不懈而闻名。Ralph Loop 正是体现了这种精神它是一个人工智能编码循环会执着地反复迭代某个主题屡败屡战直到最终成功。尽管 Ralph Loop 功能强大但它存在一个重大的根本问题缺乏任务跟踪器。随着复杂性的增加以及多个 AI 编码代理同时运行开发人员需要更高的可见性、协调性和控制力。总目标如何实现工程师不参与代码编写过程中的工程规范问题该工程范式的重点关注内容六个方面:一、指令文件结构化巨型指令文件的三个死因挤占上下文文件过大消耗 token 预算无法维护内容膨胀后难以更新无法机械验证缺乏自动化校验手段核心设计理念设计一个地图式 Agent而非全量化知识库 Agent 来进行情境管理。一份简短的AGENTS.md约 100 行被注入到情境中主要用作地图指向其他地方更深层次的真实信息来源文档体系设计文档已被编目和索引包含验证状态和一套核心理念定义了智能体优先的操作原则架构文档提供域和包分层的顶层地图质量评分对每个产品领域和架构层进行评分并随时间追踪差距计划管理临时轻量计划用于小幅变更复杂工作记录在执行计划中附带进度和决策日志版本控制活跃计划、已完成计划和已知的技术债务都已进行版本控制并集中存放目标使智能体能够在不依赖外部情境的情况下运行渐进式披露智能体从一个小而稳定的切入点开始并被指导下一步该去哪里查看而不是一开始就被淹没。二、人类 vs Agent 的能力边界人类的时间和注意力是固定的限制因素团队的想法 VS Agent 能知道的可操作化原则直接可读应用程序的 UI、日志和应用指标等内容必须直接可读版本化工件一切决策、规范、计划都必须以版本化工件提交到仓库优先上游技术选择 API 稳定、训练集覆盖好的上游技术即可以完全内化于在仓库中进行推理的依赖项和抽象让应用对智能体可操作能力实现方式独立工作区根据 git worktree 启动 → 每次变更启动独立实例浏览器控制Chrome DevTools 协议接入智能体运行时 → DOM 快照、截图、导航可观测性本地可观测性堆栈LogQL 查日志、PromQL 查指标→ 临时环境任务完成即删除三、文档约束的弱化与Agent边界的强化文档是弱约束文档的维护困难和执行的选择性使其无法作为强约束保证 Agent 的边界维护 Lint将维护指令文档深化到维护 lintLint 最早指 C 语言静态分析程序现在泛指所有代码检查工具如 ESLint、ruff、golangci-lint、pylint 等严格的架构模型围绕一个严格的架构模型构建应用每个业务域划分为一组固定的层依赖方向经过严格验证仅允许有限的一组边依赖规则示例在每个业务领域内例如应用设置代码只能向前依赖于一组固定的层Types → Config → Repo → Service → Runtime → UI横切关注点认证、连接器、遥测、功能标志通过一个单一的显式接口进入Providers其他任何内容都不被允许并将通过自动化方式强制执行自定义 Lint 与结构测试通过自定义的代码检查器和结构测试来强制执行这些规则并辅以一小套品味不变式。示例规则结构化日志记录模式和类型的命名约定文件大小限制特定平台的可靠性要求由于这些 lint 是自定义的我们编写错误信息时会在智能体情境中注入修复指令。四、吞吐量改变合并理念PR 生命周期很短测试偶发失败通过后续重跑解决在智能体吞吐量远超人类注意力的系统中这通常是正确的选择成本权衡纠错成本低而等待成本高。五、完全自主 Agent 的坏模式问题问题坏模式复现完全自主的智能体也会导致坏模式复现。解决方案黄金原则将主观的**“黄金原则”**内容直接编码到代码仓库中并建立一个循环清理流程。黄金原则示例优先共享工具更倾向于使用共享的实用程序包而不是手工编写的辅助工具以便将不变式集中管理禁止 YOLO 探测不使用YOLO 式探测数据 — 采用验证边界或依赖类型化的 SDK这样智能体就不会意外地基于猜测的结构进行构建自动化维护定期运行一组后台 Codex 任务扫描偏差更新质量等级发起有针对性的重构 Pull Request技术债务哲学理解角度技术债务就像一笔高息贷款不断地以小额贷款的方式偿还债务总比让债务不断累积再痛苦地一次解决要好得多。人类的品味一旦被捕捉就会持续应用于每一行代码每天发现并解决不良模式而不是让它们在代码库中传播数天或数周六、架构连贯性的长期演进核心问题架构连贯性会如何随着时间的推移而演变答案设计环境、反馈回路和控制系统以实现大规模构建和维护复杂、可靠的软件。to be continued参考文献https://openai.com/zh-Hans-CN/index/harness-engineering/https://github.com/deusyu/harness-engineering/