Harness十篇博客

propmt1. Harness engineering (OpenAI)关于如何通过约束与验证构建可靠agent-first软件的实践报告。​2. Building Effective AI AgentsAnthropic关于何时使用工作流或自治代理以及如何组织系统的实践指南。​3. Writing effective tools for AI agents讲解如何设计工具接口使代理更稳定且更安全地调用工具。​4. Effective harnesses for long-running agents讲解长时代理运行中状态维护、可恢复性与可靠性的实践指南。​5. Harness design for long-running application development关于通过harness结构改进长任务应用生成的后续文章。​6. Improving Deep Agents with harness engineering说明仅通过harness改进也能显著提升基准表现。​7. Evaluating Deep Agents: Our LearningsLangChain关于有状态、长时代理评测设计的实战经验总结。​8. Your Agent Needs a Harness, Not a Framework强调代理系统应优先建设可靠性基础设施而非仅依赖框架思维。​9. Skill Issue: Harness Engineering for Coding Agents实践向拆解编码代理效果很大程度取决于harness的工程配置。​10. Harness Engineering (Martin Fowler)从架构视角讨论harness engineering与系统熵控制。一、 什么是Harness EngineeringHarness Engineering是为AI智能体设计和构建系统性运行环境的一整套工程实践其核心思想是承认并接受大语言模型LLM本身固有的不确定性“概率性执行”转而通过设计精良的工程基础设施来引导、约束、验证和增强AI的行为使其能够在长周期、有状态的复杂任务中达到生产级别的可靠性与安全性。这一理念标志着工程重心的转移从追求“最聪明的AI”转向构建“能让AI稳定工作的最佳环境”根据LangChain的实践优化Harness可以使智能体的效能提升高达26%。Martin Fowler更将其视为控制软件系统熵增、维持长期可演化性的关键架构手段。二、 Harness工程的三大核心支柱分析十篇核心博客我们可以将其核心主张归纳为三个相互关联的支柱如下表所示核心支柱核心目标通俗比喻涉及的关键博客编号架构约束 (Architectural Constraints)为AI的行动划定安全、可控的边界引导其在预设轨道内高效、稳定地行动。为AI铺设“跑道”和“护栏”防止其“脱轨”。1 2 3 8 10上下文工程 (Context Engineering)为AI提供长期、结构化的“记忆”与知识解决跨步长与跨会话的健忘问题。为AI配备外部“笔记本”和“知识库”弥补其短时记忆的不足。4 5 7反馈闭环 (Feedback Loops)在AI执行过程中嵌入自动化验证与评估形成“执行-检验-优化”的良性循环。为AI配备“实时教练”和“质检员”及时纠正错误。1, 5 6 7 9三、 博客1. Harness engineering (OpenAI)约束与验证的奠基之作构建以Agent为中心的软件不能只依赖其智能必须前置性地植入明确的行动规则约束并在每一步之后进行自动化的结果检查验证这好比让一位实习生操作重要系统必须先设置其操作权限不能访问敏感数据并要求他每完成一步都截图汇报以便审核。专业要点与实战建议约束先行在Agent行动前通过工具接口的权限控制、参数白名单和沙箱环境等技术手段定义其可操作范围。验证即时将验证逻辑如代码测试、输出格式检查嵌入Agent的行动循环中形成“行动-验证”的原子操作单元。范式转变标志着软件工程从“确定性编程”向“概率性智能体的可验证性工程”转变。2. Building Effective AI Agents (Anthropic)工作流与自治的模式选择Anthropic强调“杀鸡不要用牛刀”并非所有任务都需要一个完全自主、自由探索的Agent。它将任务模式分为两类工作流模式步骤清晰、路径明确的任务如数据ETL流程。AI只需按预设指令逐步执行。自治代理模式目标开放、需要创造性探索的任务如市场策略分析。驾驭核心Harness工程首先要求我们对任务进行模式识别。对于可流程化的任务优先设计为工作流这是最高效、最可靠的架构约束。代码示例工作流模式设计# 一个简单的数据处理工作流Harness示例 workflow_steps [ {action: download_dataset, params: {url: ...}}, {action: validate_schema, params: {expected_columns: [...]}}, {action: clean_missing_values, params: {strategy: mean}}, {action: generate_report, params: {format: markdown}} ] for step in workflow_steps: # Harness 调用相应的工具并执行验证 result execute_tool_with_validation(step[action], step[params]) if not result[success]: # 工作流中断Harness 触发错误恢复机制 handle_workflow_failure(step, result) break # 保存步骤状态实现可恢复性 save_checkpoint(step, result)3. Writing effective tools for AI agents工具设计的黄金法则工具是AI与真实世界交互的“手”这篇文章教我们如何打造既灵活好用又不会“手滑”伤人的工具。专业要点与实战建议强类型契约使用如Pydantic的模型严格定义工具输入输出减少AI的解析歧义。防御性内置在工具内部而非外部进行权限、参数有效性和边界检查遵循“永不信任AI输入”原则。结构化错误所有错误信息都应机器可读包含错误类型和建议的补救措施便于Harness的错误恢复逻辑处理。标准化接口采用模型上下文协议MCP等标准可以提升工具的可发现性和互操作性。4. Effective harnesses for long-running agents长时任务的可靠性基石解决“AI干到一半崩溃或失忆”问题的指南核心在于将AI的“思维过程”和“任务进度”外化并持久保存。关键技术点状态持久化定期将Agent的当前目标、已完成步骤、中间结果等状态保存到数据库或文件系统。检查点机制将长任务分解为多个原子性子任务每完成一个就创建一个“检查点”失败后可从此恢复。操作幂等性确保工具被重复调用时不会产生副作用。例如create_file工具在文件已存在时应视为成功。技术示例状态外化// 持久化的任务状态示例 (保存在如 task_state.json 中) { task_id: refactor_module_a, current_phase: code_generation, last_successful_step: 5, context: { requirements: ..., code_snippets_analyzed: [...] }, artifacts: { generated_files: [/path/to/file1.py, /path/to/file2.py] } }5. Harness design for long-running application development项目级驾驭架构这是第4篇的进阶关注如何驾驭一个完整的、由AI参与的应用开发项目它需要一个项目级的“指挥中心”Harness。核心设计结构化全局上下文一个集中式的知识库如项目文档、架构图、API契约供所有参与该项目的Agent或工作流查询和更新。分层与编排主Harness负责任务分解和分发将不同子任务如前端开发、后端逻辑、数据库设计分配给更专业的子Agent或工作流。集成验证流水线在关键节点自动触发构建、测试和部署验证确保各模块的集成一致性。6. Improving Deep Agents with harness engineering性价比最高的优化路径优化驾驭系统比单纯升级大模型往往能带来更高的投资回报率ROI与其花费巨资换取模型能力百分之几的提升不如优化上下文检索策略、工具调用逻辑等可能带来两位数百分点的性能飞跃。专业意义为技术决策提供了明确的优先级指导。在资源有限的情况下应优先投资于Harness基础设施的建设这是提升Agent综合表现可靠性、成本、速度的最有效杠杆。7. Evaluating Deep Agents: Our Learnings (LangChain)超越结果的评测设计评测一个完成一次聊天的AI和评测一个能进行多步编码的AI复杂度天差地别后者需要一套全新的评测体系。关键评测维度过程指标任务成功率、平均步骤数、工具调用准确率、无效动作比例。资源效率总Token消耗、API调用成本、任务执行时间。环境逼真度评测必须在真实或高仿真的环境中进行如真实的Git仓库、可交互的Shell而非纯文本模拟。可观测性评测系统必须能完整记录Agent的思考链、工具调用序列和中间状态以便进行根因分析。8. Your Agent Needs a Harness, Not a Framework从框架思维到基础设施思维早期AI开发依赖框架如LangChain快速组装原型这就像用乐高积木搭了一辆车要让这辆车真正上路你需要的是公路执行环境、交通规则约束、安全气囊错误处理和维修站状态恢复——这些就是Harness。框架提供组件而Harness提供生产级的可靠性与可维护性。实战建议在技术选型时应明确区分框架与Harness。框架解决“如何快速连接与调用”的问题而Harness解决“如何在复杂现实世界中稳定运行”的问题。后者是项目进入生产阶段的必备条件。9. Skill Issue: Harness Engineering for Coding Agents编码代理的故障排查清单当你的编码Agent表现不佳时先别急着责怪模型这篇文章提供了一份工程化的“体检清单”上下文检查是否提供了完整的项目结构、相关的代码文件、依赖说明requirements.txt或package.json工具链检查代码格式化black/prettier、静态检查linter、测试运行pytest、依赖安装等工具是否已正确集成并能被Agent安全调用验证流水线检查Agent生成的代码是否能自动触发单元测试、集成测试测试失败后是否有清晰的反馈机制指导Agent修正流程设计检查复杂功能开发是否被拆分为“需求理解-接口设计-代码实现-单元测试”的标准化工作流10. Harness Engineering (Martin Fowler)控制熵增的架构哲学软件系统天然趋向混乱熵增。传统开发中熵增是缓慢的而AI的引入由于其快速生成大量可能不一致、不规范代码的能力会急剧加速熵增Martin Fowler将Harness Engineering视为一套**“负熵”系统**。专业洞见预防性约束通过架构约束如强制代码规范、分层设计从源头阻止混乱产生。纠正性反馈通过自动化测试、代码评审和重构建议持续清理已产生的混乱。架构师的视角Fowler将Harness提升到软件架构的核心地位认为它是确保AI增强型系统长期保持整洁、可理解和可演化的关键设计决策。四、 总结一种系统性的设计思维和工程实践集合。它要求开发者完成三重角色转变从“魔术师”到“工程师”从依赖提示词技巧转向构建可测试、可验证、可重复的工程系统。从“组件组装者”到“环境架构师”从使用框架搭建功能转向设计包含状态、记忆、工具和验证的生命周期环境。从“追求峰值性能”到“保障基线可靠性”首要KPI从任务完成率转向成功率、成本、耗时和可恢复性的综合考量。未来Harness Engineering将呈现两大趋势一是标准化与产品化类似Vercel的AI SDK、Claude Code SDK等项目正将最佳实践封装为易用的工具二是“Harness as Code”即用声明式代码来定义和版本化Agent的运行环境实现基础设施即代码IaC理念在AI领域的延伸