行业投资评级 - 报告未明确给出计算机行业的整体投资评级 [1][2][3][4][5] 报告核心观点 - **Harness Engineering（驾驭工程）成为AI软件工程新风口**：报告认为，由OpenAI和Anthropic提出的Harness Engineering是一种全新的工程范式，它作为AI时代的操作系统和软件工程方法论的统一体，旨在通过优化Agent（智能体）的记忆、提示词、知识库、编排以及多Agent协作，来提升开发效率和业务创新力 [1][2] - **Claude Code源码泄露有望加速AI Agent行业发展**：Anthropic因操作失误导致Claude Code约**51.2万行**源代码泄露，涉及**4756个**源文件及多项未发布功能，这虽然暴露了供应链安全问题，但大幅降低了AI Agent的研发门槛，可能加速行业竞争与技术创新 [3] Harness Engineering 范式详解 - **定义与作用**：Harness是一种支撑复杂AI智能体运行的外部框架、控制结构与编排系统，是一整套工程化的“脚手架”，用于管理和放大AI的能力，其核心作用是解决AI在完成复杂、长时任务时的“失控”问题 [1][2] - **实践成果**：OpenAI的一个实验显示，一个由**3名**（后扩展至**7名**）工程师组成的团队，在**5个月**内使用Codex Agent生成了超过**100万行**生产级代码，合并了约**1500个** Pull Request，且没有一行代码是人类手写的 [1] - **与Prompt的区别**：Prompt决定了单次对话的质量，而Harness决定了多轮、多智能体、长时任务的执行流程和可靠性 [2] - **行业共识**：无论是OpenAI还是Anthropic，都明确认定Harness是Coding Agent落地的关键 [2] Claude Code 源码泄露事件分析 - **事件概况**：2026年**3月31日**，Anthropic因npm包打包失误，导致Claude Code的**51.2万行**源代码被动“开源”，内容包含**4756个**源文件、**40余个**工具模块及多项未发布功能（如Kairos持久进程、卧底模式） [3] - **影响评估**：泄露内容未涉及模型权重与用户数据，但暴露了其架构、提示词及工具调用机制，为外界提供了迄今最完整的Claude Code架构视图 [3] - **潜在影响**：此次事件是Anthropic同类二次失误，引发了对供应链安全的质疑，但泄露的代码已在社区扩散，将大幅降低AI Agent研发门槛，可能加速行业竞争与技术创新 [3]

行业背景与核心问题 - AI正逐渐成为互联网内容的主要消费者，但当前互联网基础设施并非为AI智能体（Agent）设计，导致其使用体验极差[1][3] - 当前互联网对Agent“极其不友好”，具体表现为：各种验证登录阻碍、工具接口混乱、调用成本高昂且成功率低，单步调用成功率仅60%，多步调用可跌至30%以下[4] - Agent的上网行为模式与人类存在本质区别：人类是浏览与思考，Agent是为完成任务而进行跨平台、长链条的工具调用，对速度和可靠性要求极高，但现有基于人类设计的网络缓存（如CDN）和UI无法满足其需求[15] - 外部工具调用是当前Agent运行的一大短板，即使简单任务也需调用十几次外部工具，链条易断，导致Agent在反复试错中浪费大量token，效率低下[14][16] Agent Internet Infra 的定义与机遇 - Agent Internet Infra 是让海量智能体能够自主发现、安全连接、可信协作的底层网络协议与中间件体系，核心解决Agent与外部连接及Agent间协作的问题[17] - 该方向核心能力包括：身份认证、通信协议、权限治理、跨平台工具调用、数据传输优化、交易支付、安全管理等[17] - 行业尚处早期，虽有Cloudflare发布Markdown for Agents、谷歌发布WebMCP等尝试，但新一代基础设施服务商仍然缺位[17] - 该赛道天花板极高，因为一个公司或个人可部署成百上千个永不休息的Agent，其承载的流量和价值上限难以估量，有望催生一批新的大公司[27] 公司战略与解决方案 - 公司AgentEarth的战略锚点是：从第一天起就把Agent视为网络的终端用户，基础设施优化方向从“服务于人类体验”转向“服务于任务完成率和效率”，并对任务结果负责[19] - 产品决策上，公司刻意不做面向人的界面和复杂开发者体验，只做标准化Agent接口，坚信未来是Agent自主装配工具，为人类设计的操作层仅是短期过渡[20] - 解决方案分为三层技术栈：1）顶层采用“自营逻辑”精选并托管高质量工具，保证早期服务质量，类似早期京东自营，未来将开放生态并引入基于大模型的智能推荐[23]；2）中间层构建面向Agent的“单一网关”，接管工具挑选、故障切换和统一结算，使调用成本透明可控[23]；3）底层通过自研的“传-存-算一体化调度协议”优化数据传输，实测比当前最好的开源协议谷歌QUIC快2-10倍，甚至达十几倍[24] - 底层协议研发周期长（以十年计），源于早期优化TCP/IP的经验积累，构成了公司的核心技术壁垒，难以被短期复制[25] 团队优势与发展现状 - 核心团队具备稀缺的复合经验：CEO刘洪涛拥有企业级基础设施从0到1的规模化验证经验；CTO单明辉曾构建和运维滴滴数亿人与海量网约车的实时大型匹配系统；首席科学家薛教授深耕国家级前沿网络技术与底层协议栈[5] - 团队在极端稳定性、效率和容错要求场景下的实战经验，在Agent调用规模起来后将变得极具价值且难以快速复制[28] - 公司已基于上述判断和优势，发布了产品测试版并开始小范围测试[29]

文章核心观点 - 行业对大模型未来发展的判断正从“推理思维”转向“智能体思维” 核心区别在于 智能体思维是为了行动而思考 在与环境持续互动、获取反馈并修正策略的过程中思考 而非仅仅在模型内部进行静态的、独白式的长链推理[2][6][9] - 未来模型能力的领先将越来越取决于谁能构建更好的环境、更紧密的训推协同、更强的harness engineering 以及将模型决策与现实后果闭环的能力 而不仅仅是模型本身的强化学习算法或训练流水线[7][24] 行业技术演进路径 - 2025年上半年 行业进入“推理模型时代” OpenAI的o1和DeepSeek-R1证明了推理能力可以被专门训练和复现 行业焦点在于如何让模型在推理阶段投入更多计算、如何用更强奖励信号训练 以及如何控制额外的推理开销[4][9] - 推理模型的出现不仅是模型层面的故事 也是基础设施层面的故事 它标志着行业从扩展预训练转向扩展面向推理的后训练 并需要大规模rollout生成、高吞吐验证等系统工程能力[10] - 行业下一阶段的核心是从“推理思维”走向“智能体思维” 即训练的核心对象从模型本身转变为“模型+环境”组成的系统 具体是智能体及其周边的执行框架[16][24] 模型架构与训练路径的探索 - 阿里千问团队在Qwen3上尝试了“混合思维模式” 旨在将thinking和Instruct模式合并到同一个模型中 以实现根据任务自动判断推理强度的理想目标 但结果并不理想 合并后两种模式的表现均受损[3][4] - 问题的根源在于数据 两种模式对应的数据分布和行为目标存在天然差异 thinking模式因在难题上投入更多token、探索备选路径而受奖励 Instruct模式则因直接、简洁、低延迟而受奖励 未经精细融合的数据会导致合并效果不佳[4][12] - 因此 实践中“分开做”依然有吸引力 Qwen在2507系列推出了彼此独立的Instruct和Thinking更新 包括独立的30B和235B版本 以满足商业客户对高吞吐、低成本、强可控Instruct模式的明确需求[13] 行业主要参与者的技术路线 - Anthropic主张一体化模型哲学 Claude 3.7被定义为带有可控预算的混合式推理模型 Claude 4允许推理过程与工具使用交错进行 其核心思路是思考应由目标工作负载（如编码、智能体工作流）来塑造 而非单纯延长推理链[5][14][15] - GLM-4.5和DeepSeek V3.1也朝类似混合推理方向迈进 关键挑战在于融合是否“自然” 成功的融合要求推理投入是一个平滑连续的谱系 模型能表达多个层级的推理强度并理想地自适应选择 而非两个生硬拼接的人格[14] - OpenAI的o1被描述为通过强化学习训练、能够“先思考再作答”的模型 DeepSeek R1则定位为可与o1竞争的开源推理模型 共同推动了以推理为中心的后训练范式[9][10] 智能体思维的内涵与挑战 - 智能体思维是一种围绕行动展开、在环境中运作、并依赖反馈闭环不断修正自身的思维能力 它需要处理一系列纯推理模型可回避的问题 例如决定何时停止思考并采取行动、选择调用工具及顺序、吸收环境噪声、失败后修订计划、在多轮交互中保持一致性等[8][17][18][22] - 智能体强化学习的基础设施比经典推理强化学习更复杂 环境（工具服务器、模拟器、API层等）成为训练系统的一部分 这要求训练与推理必须更彻底地解耦 否则整条流水线的GPU利用率会远低于经典水平[19] - 环境质量成为核心研究对象 包括稳定性、真实性、覆盖面、反馈丰富度等 环境构建正从一个“副项目”变成一个真正的创业赛道[20] - 训练智能体系统面临更严峻的reward hacking挑战 例如模型学会直接搜索答案、利用代码仓库未来信息或发现任务失效捷径 下一批研究瓶颈将来自环境设计、评估器鲁棒性、反作弊协议等方面[21][23] 未来竞争格局与能力构建 - 未来智能体能力的核心 越来越不只来自模型本身 也来自围绕模型搭建的“脚手架” 即环境、工具、约束、反馈循环以及多智能体协同机制 Harness Engineering的价值在于把“裸模型”变成能在现实任务中持续工作的Agent[7] - 未来的核心智能将越来越多地体现在多个智能体的组织方式上 例如负责规划的协调器、领域专家智能体、处理窄任务的子智能体 演进路径是从训练模型 走向训练智能体 再走向训练系统[23] - “好的思考”的定义发生改变 真正有价值的不是最长、最显眼的思维轨迹 而是在现实约束下最能支撑持续行动、最能在环境中有效运作、并能通过反馈闭环不断修正的那种思考[24]

生成式AI算法与模型优化 - 谷歌发布TurboQuant压缩算法，通过极坐标变换与1-bit误差校验，将KV缓存压缩至3-bit，使内存占用降低6倍，推理速度提升8倍，无需重训或校准数据，在长上下文基准测试中性能接近全精度模型[1] - 英伟达提出智能体式变异算子AVO，用自主编码智能体替代传统进化搜索，在Blackwell B200 GPU上连续自主运行7天，其生成的注意力内核在BF16精度下达1668 TFLOPS，性能超越英伟达官方cuDNN最高3.5%，超越FlashAttention-4最高10.5%[3] - Meta提出超级智能体HYPERAGENTS，结合哥德尔机思想与达尔文开放算法，使智能体不仅能完成任务还能优化“改进自身”的底层逻辑，在SWE-bench上性能从20%自动提升至50%，并具有跨领域迁移能力[4] 生成式AI应用与产品动态 - 谷歌发布AI音乐模型Lyria 3 Pro，可生成最长3分钟完整歌曲，支持前奏、主歌、副歌等结构化编排及精确控制节奏与歌词时间轴，并通过Gemini App、API、Google Vids等多入口全面开放[2] - OpenAI因成本压力关停Sora，半年仅赚210万美元且与迪士尼的10亿美元合作泡汤，而谷歌选择将生成能力嵌入已有产品生态[2] - Sakana AI等团队提出的AI Scientist系统实现科研全流程自动化，能自主生成研究思路、编写代码、运行实验、撰写论文并进行同行评审，其生成的一篇论文获得ICLR 2025研讨会6.33分评审成绩[7] AI行业趋势与竞争格局 - AI工程方法正经历从Prompt Engineering到Context Engineering再到Harness Engineering的演进，Harness包含记忆管理、工具技能等六大组件，核心原则是精准信息披露、工具精简和上下文利用率控制在60%以下[9] - 智能体时代的竞争优势正从RL算法转向环境质量、训练推理紧耦合和harness工程能力，reward hacking被视为最大技术挑战[8] - 模型公司与应用公司的竞争已从模型层转向“模型+harness”整体，下一代范式可能是多智能体协调工程[9] 地缘政治与市场影响 - NeurIPS新增条款禁止美国OFAC制裁名单上的机构投稿和参与审稿，涉及华为、商汤、中芯国际、海康威视等873条中国相关名单条目，引发中国学界抵制[5][6] - 中国学者已成NeurIPS核心力量，清华大学以390篇论文位列NeurIPS 2025全球第一，此举被批评为将学术交流政治化[6] - 谷歌TurboQuant算法消息引发存储芯片板块集体重挫，美光、西数等巨头股价全线下跌，但业界认为杰文斯悖论可能使实际内存需求不降反升[1] 中国市场与基础设施预测 - Gartner预测到2030年中国80%本地AI基础设施将采用国产AI芯片，目前仅为20%，出口限制推动了自主研发进程和本土市场保护[10] - 到2028年跨区域合规与AI偏见问题将占AI数据管理量的50%，企业需通过数据属地化等方式应对多区域模型混用带来的合规风险[10] - 到2029年70%的中国企业将落地正式AI安全测试，AI智能体将承担大型企业超40%的IT运营任务，“智能体化企业”是下一阶段方向[11]

文章核心观点 - 随着基础模型能力成熟，决定智能体（Agent）能力上限的关键不再是模型本身，而是围绕模型构建的整套外围系统，即“Harness Engineering”（驾驭工程）[1] - Harness Engineering 是继提示工程、上下文工程之后AI工程方法的最新演进阶段，其核心价值在于通过系统设计捕获高质量的执行轨迹，形成数据飞轮，构建长期竞争优势[1][3] - 模型与Harness的关系日益紧密，呈现“训练即部署”的特点，Harness的能力正被快速吸收进模型，同时其本身作为高质量数据集的角色也使其成为竞争壁垒[31][34][36] AI工程方法的演进 - **Prompt Engineering (2022-2024)**：聚焦于单次对话中指令的打磨，通过优化提问方式让模型更稳定地输出预期结果[3] - **Context Engineering (2025)**：关注在有限的上下文窗口内，如何高效地获取、压缩和组织背景信息[3] - **Harness Engineering (2026)**：关注构建完整的运行环境与管控系统，包括工具、记忆、评估等组件，使智能体能可靠、安全地完成任务[3] - 演进背后的共同逻辑是：一旦模型能力过线，瓶颈就会开始外移[3] - 标志性事件是2025年11月Claude Opus 4.5的发布，意味着模型智能体能力达到临界点，系统层成为新瓶颈[4] Harness的关键组件 - **记忆与上下文管理**：解决智能体在当前时刻应看到什么信息，涉及上下文裁剪、压缩、检索和外部存储[5] - **工具与技能**：扩展智能体的行动能力，工具提供外部调用能力，技能提供可复用的任务方法[5] - **编排与协调**：负责编排复杂任务流程，协调多个智能体的分工与交接[5] - **基础设施与保障**：提供沙箱、权限控制、失败恢复和安全护栏等运行环境与边界条件[5] - **评估与验证**：内置测试、检查和反馈机制，使智能体能自行验证并修正工作[6] - **追踪与观测**：提供执行轨迹、日志、监控和成本分析，使系统可调试、可优化[6] - 六个组件可归纳为三层逻辑链路：信息层（准备信息）、执行层（推动执行）、反馈层（复盘结果）[6] Harness的设计原则与技巧 信息层原则：精准比求全更重要 - **渐进式披露**：将信息分层加载，让模型在不同阶段只接触必要信息。例如Claude Code将信息分为三层：CLAUDE.md（核心元规则）、SKILL.md（按需调用的能力包）、参考资料与脚本[10][11][12] - **工具少而精**：模型能力提升应减少对外部工具的依赖，过于复杂的工具集是模型幻觉的温床。Claude Code仅保留约20个工具，且谨慎新增[13] - **控制上下文窗口利用率**：存在利用率“甜蜜区间”，超过后性能下降。一项测试显示，当输入token从256K增至1M时，主流大模型表现明显下滑。顶级工程师常将上下文利用率控制在60%以下[15][17] - **利用子智能体进行上下文隔离**：将子任务分配给独立的子智能体，在主智能体更干净的上下文中进行调度与汇总，该方法被称为“context firewall”[18] 执行层原则：设计清晰的任务结构 - **分离研究、计划、执行、验证**：将任务链拆分为四个独立会话，避免上下文污染。例如，Claude Code要求对任何非简单任务（超过3步或涉及架构决策）先进入规划模式，执行前清空上下文[20][21][22] - **人类介入应前置到规划环节**：将精力从事后审核前移至研究和规划阶段，因为糟糕计划的影响远大于单行代码错误[24][25] 反馈层原则：构建复利飞轮 - **核心逻辑**：每一次失败都是让系统永久变好的机会，需将经验沉淀到规则文件中（如AGENTS.md）[27] - **构建自动化反馈闭环**：为智能体提供验证手段可显著提升产出质量。例如，提供有效验证后，Claude的产出质量能提升2-3倍。方法包括：让另一智能体验证结果、使用插件进入“自动迭代模式”、让智能体自行测试UI等[28] - **设计可迭代的回路**：重点不在于单次输出，而在于设计能不断筛选、迭代的闭环，此模式适用于研究、优化转化率等多种场景[29] 模型与Harness的共生关系 - **训练即部署**：在智能体强化学习的训练逻辑中，模型与Harness从一开始就共同设计。训练效果高度依赖于“训练场”是否贴近真实世界，模型在训练阶段接触的环境、工具和反馈决定了其上线后的表现[32] - **Harness能力被模型内化**：模型公司正将“模型+Harness”作为整体优化。许多原本属于Harness的能力（如工具搜索、程序化工具使用、上下文压缩、多步调用策略）正通过后训练被模型吸收，形成“Harness优化-模型内化-新Harness设计”的循环[34][35] - **Harness即数据集**：真正的竞争优势在于Harness捕获的执行轨迹数据，包括智能体看到的信息、使用的工具、决策过程及错误点。Harness成为模型能力生成的土壤，反哺智能生长[36] - **当前的竞争态势**：即使模型能力打平，优秀的Harness设计（如Claude Code）仍能赢得用户。同时，头部模型公司端到端做Harness，而大型AI应用公司也开始基于自身业务数据和Harness训练模型，竞争焦点转向在特定场景构建成本更低、效果更好的系统[37][38] 创业公司的机会与代表项目 信息层 - **机会领域**：以智能体为中心，抓取企业内分散的隐性知识，将其转化为可执行的动态上下文[40] - **代表公司：Edra**：定位为“Context for Agents at Scale”，通过读取企业工单、日志、邮件、聊天记录等数据，反向推理还原业务流程，并整理成智能体可复用的操作手册。2026年3月完成约3000万美元A轮融资，由Sequoia领投[41] 执行层 - **方向1：工作流编排/持久化执行** - **代表公司：Temporal**：提供持久化执行底层基础设施，确保长时、复杂任务在中断后能从断点恢复。已签约OpenAI、Replit、Netflix等大客户。2026年2月完成3亿美元D轮融资，a16z领投，估值达50亿美元[42] - **方向2：安全与治理** - **代表公司：Oasis Security**：面向智能体企业的权限管理平台，管理AI数字身份的权限、追踪与控制。2026年3月完成1.2亿美元B轮融资，Craft Ventures领投，估值7亿美元[43][44] - **方向3：沙箱** - **代表公司：Daytona**：提供智能体长期使用的、有状态的沙箱工作空间，支持长周期复杂工作流。2026年2月完成2400万美元A轮融资，FirstMark领投[45] 反馈层（评估与可观测性） - **看好原因**：1) 企业需要独立的质量控制面板；2) 是AI企业的刚需痛点，且需求将随智能体复杂度增加而增长；3) 深度嵌入工作流，替换成本高[46] - **代表公司：Braintrust**：AI可观测性与评估平台，功能包括：记录生产环境调用轨迹、对结果进行多方式评分、利用线上问题沉淀测试集以优化产品。2026年2月完成8000万美元B轮融资，ICONIQ领投，估值8亿美元[47][48] 未来展望：协调工程 - **下一阶段范式**：可能为“Coordination Engineering”（协调工程），即协调无数智能体或人机节点共同完成高度复杂任务，类似于“小龙虾版飞书”的监工看板与协作平台[48][49] - **智能体工程的终极范式**：可能包含四个层级：L1解决问答质量（提示工程）、L2解决认知边界（上下文工程）、L3解决执行闭环（驾驭工程）、L4解决组织协同（协调工程），它们之间是包含而非替代关系[49]

Agent工程范式从Context Engineering向Harness Engineering演进 - 行业关注重点正从AI的生成能力转向执行能力，长程任务中的上下文挤压、工具开销和业务语境缺口问题凸显，单一的Context Engineering已难以支撑Agent稳定运行，围绕执行环境、约束机制和反馈回路设计的Harness Engineering受到更多关注[1] - Harness Engineering被视为继Prompt Engineering、Context Engineering之后，Agent工程进一步走向执行框架设计的新信号，其核心判断是决定Agent落地效果的关键已不只是模型能力，更在于系统能否提供清晰边界、自动校验和可复用的纠错流程[5] - 新的工程分工正在形成，模型负责生成与执行，人类则更多负责设定约束、补充反馈并持续优化运行框架[6] Context Engineering的局限性 - 随着AI应用从单轮问答走向多步执行与长链路任务，单靠提示词（Prompt Engineering）已难以覆盖真实任务中的上下文缺失、信息噪声与工具协同问题[7] - Context Engineering的核心是系统化设计推理所需的信息供给，包括检索、记忆、工具反馈与上下文组织，以减少执行偏移和结果失真，曾被Andrej Karpathy认为是工业级LLM应用的关键[8] - 但在更长链路、更高复杂度的真实任务中，Context Engineering的局限性集中暴露，包括受限于上下文注意力预算、工具接入和协议开销挤压有效认知空间，以及难以自动补齐关键的业务定义和组织隐性知识[8] Harness Engineering的价值与成效 - Harness Engineering的价值不依赖于更换底层模型，可直接体现在系统层优化上，例如LangChain团队在固定模型不变的前提下实现了Agent表现的明显提升[6] - 具体案例显示，LangChain的Deep Agents团队在2025年2月保持模型为GPT-5.2-Codex不变，仅通过调整harness，就将coding agent在Terminal Bench 2.0上的得分从52.8%提升至66.5%，排名从Top 30附近跃升至Top 5[6] - 其改进方法是借助trace在大规模运行中识别失败模式，再针对性回写到harness中，这意味着Harness Engineering将“调试模型”转化为“调整系统”，通过可观测性与闭环迭代持续放大模型已有能力[7] - 行业观点认为，当Agent反复犯同类错误时，关键在于让系统更快暴露错误、定位错误并推动修正，这正是Harness Engineering的实践范畴[5]

核心观点 - 开源个人AI助手OpenClaw的核心是一个极简框架Pi-coding-agent，其设计哲学是做减法，通过不到1000 tokens的系统提示词和核心工具实现高效编码，在性能基准测试中进入前五 [1][2] - 框架创始人认为，经过大量强化学习训练的大模型已天然理解编码工作流，无需复杂预设，因此Pi框架坚持极简、可扩展、确定性和高可观测性，以对抗主流AI编程工具因频繁静默更新而破坏开发者工作流的问题 [2][5][7][9][36] - 在Pi框架下，不同用户发展出多样化的工作流，但其核心价值在于提供了一个可构建个性化智能体的基础，而非一个功能固化的产品 [20][21][22] - 框架创始人强烈反对在功能构建中使用并行子智能体模式，认为这会导致代码质量低下，并强调人类在开发循环中保持最终决策权的重要性 [23][24][25][26] - 对于AI编程工具的安全和长期记忆问题，创始人认为现有权限系统多为“安全剧场”，而代码库本身即为最佳真相源，无需额外的复杂记忆系统 [28][29][31] Pi框架的极简设计理念与实现 - 系统设计极简，系统提示词和工具定义总计不到1000 tokens，而Claude Code超过10000 tokens [10] - 核心工具只有read、write、edit、bash四个，没有内置计划模式、待办系统、MCP支持或权限弹窗 [2] - 将LLM视为“用自然语言编程的通用计算机”，提示词如同代码，状态序列化到磁盘文件，从而绕过上下文衰减问题 [11] - 主动选择不支持MCP，以避免大量未使用的工具定义消耗上下文窗口，替代方案是编写带README的CLI工具，按需调用 [12] - 不内置计划模式，通过让智能体读写`PLAN.md`文件来实现跨会话规划，且过程完全可观测 [12][13] - 不内置待办系统、后台bash功能和子智能体，以降低复杂性并保持完全的可观测性与控制权 [14][15] 对主流AI编程工具的批判与Pi的动机 - 创始人因受够了Claude Code等工具频繁变更的“工作流”而开发Pi，这些工具会静默更新系统提示词和工具定义，导致开发者工作流被破坏 [5][7][9] - 主流工具如Claude Code和Codex会在用户上下文中静默注入内容，且发布节奏极快，导致模型行为在短时间内发生不可预测的变化 [7][36] - 创始人开发了`cchistory`工具追踪Claude Code的变更，发现了大量用户不知情的“静默调整”，这些调整会微妙地改变模型行为 [35][36] - 当前AI工程实践被形容为“基于氛围的工程”，因为自然语言接口、MCP服务器、系统提示词等各层都在不断变化且缺乏能见度，导致开发者被“煤气灯效应” [36] 用户工作流与实践案例 - 用户Daniel的工作流：使用定制的头脑风暴技能生成激进、务实、豪华三种方案并讨论确定，产出Markdown计划和待办事项 然后使用侦察子智能体探索代码库，将结果传递给使用Sonnet 4.6的“工人”智能体实施 实施后使用Codex审查子智能体进行代码审查，并利用剩余上下文窗口进行高效的迭代修复 [21] - 用户Armen的工作流：替换了Pi内置的编辑工具为支持基于补丁的多文件编辑版本 开发了`answer`扩展，将模型问题提取并渲染为UI逐一回答，不消耗上下文 让智能体在验证改动时自动截图，并能在后续会话中重新查看 [22] - 创始人Mario的个人使用方式极为简约，仅使用两个针对特定项目的扩展，旨在为用户提供一个可自定义的“元工具”，而自己保持斯巴达式体验 [22] 对并行子智能体与权限系统的看法 - 创始人认为让多个子智能体并行开发不同功能是一种“反模式”，除非不介意代码库质量下降，他强调人类需要保持在开发循环中并做最终决策 [23][24][25] - 对于需要探索的任务，如优化方案探索，子智能体可能有效，但对于真正的功能构建，仍需人类监督和串行流程 [27] - 认为当前大部分编程智能体的权限系统是“安全剧场”，只要智能体具备写代码、执行代码和网络访问能力，就无法真正防止数据泄露 [28][29] - 权限弹窗会导致“权限疲劳”，用户最终会习惯性同意或跳过所有权限，使系统形同虚设 [28] - Pi框架因此不设权限系统，默认全开，建议对敏感数据使用Docker容器进行隔离 [29][30] 对长期记忆与代码上下文的看法 - 认为对于编程任务，不需要额外的长期记忆系统，代码库本身就是真相源 [31] - 高度评价Claude Code发明的“搜索”方式，即让智能体从零开始探索代码库当前状态，这比维护过时的文档更有效 [32] - 用户Daniel尝试过会话摘要续接的方法，但发现用处不大，最终采用本地`agents.md`文件记录需要智能体记住的信息 [32] - 用户Armen尝试将最近的Git变更推入上下文以帮助续接，但效果好坏参半，尚未被说服 [33] AI生成内容对开源社区的挑战与应对 - 开源项目面临大量完全由AI生成、无人监督的issue和PR涌入，一个PR可能修改30到100个文件，审查负担极重 [38] - AI在判断issue或PR是否与项目相关、质量是否达标、是否符合项目理念方面表现糟糕，仍需人类大脑判断 [38] - 创始人建立了一套防御系统：要求贡献者必须先以“人类的声音”开一个issue，经确认后其账号被加入白名单，才能提交PR，否则PR会被自动关闭 [38] - 此方案对PR有效，因为AI通常不会回去读自动关闭的评论，但对提交门槛更低的issue仍是一个难题 [38]

Harness Engineering的兴起与定义 - 2026年开年，开发者社区最热关键词为Harness Engineering，由HashiCorp联合创始人Mitchell Hashimoto在2月5日命名[2] - 一个月内，该概念从一篇博客文章发展为开发者社区高频词[3] - 行业新共识：在AI Agent编码领域，决定结果好坏的最大变量是模型所处的环境，而非模型本身[4] - 核心观点：模型能力竞赛持续，但决定Agent工程产出质量的杠杆已转移到“环境”一侧，这个环境就是Harness[5][6] 从Prompt到Context再到Harness的认知演进 - **2023年：Prompt Engineering全盛期**，焦点是写好单条提示词，但处理复杂任务时局限性暴露[9] - **2025年中：Context Engineering兴起**，焦点从“写好一条指令”扩展到“设计动态系统来组装上下文”，包括RAG、对话历史等编排[9] - **2026年2月：Harness Engineering正式命名**，解决了Context Engineering的不足，即上下文无法阻止Agent“做不该做的事”[11][12] - 三阶段关系总结：Prompt Engineering管“说什么”，Context Engineering管“知道什么”，Harness Engineering管“在什么环境里做事”[13] OpenAI实验的核心发现与工程实践 - **实验设定**：5名工程师在五个月内，通过Codex Agent协作交付了超过100万行代码的生产级软件产品，无一行人类手写代码[4][15] - **效率数据**：平均每名工程师每日合并3.5个Pull Request，代码审查通过Agent对Agent循环实现大规模自动化[15] - **关键挑战**：最困难的挑战集中在设计环境、反馈回路和控制系统上[15] - **文档工程进化**：从将所有信息塞进庞大AGENTS.md文件的错误，演变为**渐进式披露模型**，AGENTS.md精简为约100行的“目录”，指向结构化docs/目录[16][17] - **超越文档**：将可观测性数据（日志、指标、追踪）直接暴露给Agent，使其能通过LogQL和PromQL查询验证运行时状态，甚至通过Chrome DevTools Protocol操作浏览器以重现Bug[18][19] - **机械化架构围栏**：通过确定性Linter（错误输出格式专为Agent设计）和基于LLM的审计Agent，严格拦截违反分层架构依赖流向的代码[21][22] Harness Engineering的三维框架（Böckeler解读） - **维度一：上下文工程**：确保Agent在正确时机获得正确信息，包括渐进式文档披露、动态可观测性数据接入[24] - **维度二：架构约束**：通过机械化手段（如专为Agent设计的Linter）强制执行架构边界，使“违规→检测→修复”循环可在Agent内部闭环完成[25] - **维度三：熵管理/垃圾回收**：部署专用清理Agent定期扫描文档漂移、模式违规和依赖问题，防止Harness自身随时间腐化[26] - 三者关系：上下文工程让Agent“知道该做什么”，架构约束确保“只在边界内行事”，熵管理保障“整个系统不随时间退化”[26] 行业实践与验证 - **Stripe的工业级实践**：其Minions体系每周合并超过1,300个由AI完全编写的Pull Request[28]。每个Agent任务在独立预热devbox中运行（约10秒启动），通过名为Toolshed的中心化MCP服务器访问近500个工具[28]。采用“蓝图”模式，混合确定性节点与Agent节点，将LLM限制在“可控盒子”里以提升可预测性[28] - **LangChain的对照实验**：其编码Agent在Terminal Bench 2.0基准测试上，仅通过优化Harness（不修改模型），得分从52.8%提升至66.5%，排名从第30跃升至第5[4][29]。这是“环境比模型更重要”的直接证据[30] - **行业采用**：Anthropic将Claude Code定位为“灵活的Agent线束”[31]。MCP（模型控制协议）月SDK下载量超过9,700万，获OpenAI、Google、Microsoft和AWS采用，正成为Agent工具访问的通用标准[31] - **行业数据**：LangChain报告显示，89%的受访者已为其Agent实施可观测性，但仅有52%实施了评估（Evals）[32] 工程师角色与组织结构的转变 - **工程师核心工作转变**：从写代码转向设计让Agent可靠运行的环境，具体包括构建文档与上下文体系、以机器可处理的方式定义业务意图、构建自动化的防呆验证机制[33] - **新工作模式**：工程师如软件架构师，只讨论高层架构和重大决策，不涉及具体代码实现[34]。系统理解的深度比写代码的速度更重要[35] - **组织结构变化**：OpenAI的3-7人团队完成了以前需数十人规模的工程输出[35]。Stripe让单名工程师可同时向多个Agent分配任务，团队结构向两三人甚至单人团队收敛[35] - **“学徒缺口”挑战**：初级开发者若过早进入Agent驱动循环，可能缺乏构建健壮Harness所需的深度系统直觉，需设计保留手动开发直觉的学习路径[35] 开发者行动建议与采用路径 - **起步**：把同一个任务做两遍（先手动，再让Agent做），以建立对Agent能力边界的直觉[36] - **养成习惯**：每天下班前30分钟启动Agent，处理深度调研、并行探索、Issue和PR分诊等任务[36] - **关键跃迁**：在项目中建立一份AGENTS.md文档，从最基本内容开始，每次Agent犯错就补充一条规则，使其逐渐长成Harness[36] - **心态建议**：关掉Agent的桌面通知，由人类控制中断时机[36] - **对技术负责人的建议**：选择新项目做试点，并建立Evals（评估体系）能力[37]

OpenAI内部开发模式的转变 - OpenAI工程师已基本不手写代码，在一个内部项目中，五个月内由Codex生成了100万行代码，构建了包括应用逻辑、基础设施、工具、文档和内部开发者工具在内的完整软件产品Beta版[2][3] - 公司内部文化为自下而上的创业公司氛围，团队小、决策快，工程师自主权高，好想法常由小团队自然形成并推进，而非来自高层制定的宏大计划[5][6][7] - 工程师的角色转变为“能力架构师”或“AI驾驭工程师”，核心工作从“写代码”变为设计环境、搭建反馈循环、定义架构约束，然后让AI智能体执行，即“人类掌舵，智能体执行”[11][12][13][14] AI驱动开发流程的核心实践 - 让应用对AI“可读”：将AI智能体接入Chrome DevTools协议，使其能像开发者一样操作页面、读取日志、抓取DOM和截屏观察界面，从而具备“眼睛”和“手”以进行测试和调试[20][40][41][42] - 将隐性知识显性化并写入代码仓库：确保所有规则和说明对机器可读，但采用“给地图而非千页说明书”的策略，提供导航而非一次性塞入所有细节，以避免上下文资源浪费和文档过时[21][22][23][24] - 设计“AI友好”的严格架构：例如强制规定每个业务域按固定层级组织，并强制依赖方向，任何违反都会被自动阻止，以此提升AI的工作效率[26][27][28] - 将人类“品味”编码为规则：将工程师的审美偏好（如文件大小限制、命名规则等）写成lint规则，使AI每次写代码都能自动遵守，实现“人类的品味一旦被捕捉，就可以应用到每一行代码”[29][30][31] - 建立自动化“垃圾回收”机制：针对AI可能复制代码库中不良模式导致的代码风格“漂移”问题，将清理原则编码进仓库，让Codex自动扫描问题并发起重构PR，防止技术债累积[32][33][34] AI智能体能力的演进 - AI智能体能够承担完整的软件开发与质量保证流程：包括写代码、启动应用、像用户一样操作UI、检查结果，并在发现问题后自动修改代码、提交PR、重启应用、重新运行任务，形成一个“发现问题 → 修改代码 → 再运行 → 再观察”的自动反馈循环，直到问题解决[44][45][47][52][53][54][56] - 智能体具备系统级的可观测能力：通过接入收集日志、性能指标和调用链的可观测系统，AI能像工程师一样排查服务错误、接口性能等问题[48][49][50] - 该全自动开发流程的成功运行高度依赖为特定代码仓库专门设计的结构和工具链，目前尚难直接照搬到其他环境[58] 对软件工程领域的潜在影响 - 软件工程的重点可能逐渐从“写代码”转向设计环境、规则和反馈机制，以使AI智能体能更稳定地参与构建和维护复杂系统[59] - 这种“AI驾驭工程”模式被视为一种现代控制论，历史上类似模式（如瓦特蒸汽机调速器、Kubernetes控制器）的出现，都意味着人的角色从执行者转变为系统的设计者和校准者[35][36]