100 万行代码没有一行是人工写的。AI 发展到现在业内顶尖的公司都是怎么做的OpenAI 和 Anthropic 不约而同提出了 「Harness Engineering」基础设施与脚手架即驭缰工程。读这篇文章你会看到三件事OpenAI 用 Agent 写了100万行代码没有一行是人工写的Anthropic让 Agent 自己迭代出了从未见过的创意飞跃字节跳动把这套方法开源上线即登 GitHub Trending 第一。它们背后是同一套框架四个组件多智能体架构、上下文管理、架构约束、反馈回路。读完你会知道这四个词具体意味着什么工程决策以及为什么同一个提示词、同一个模型有没有这套框架结果差了20倍。01为什么是现在2023-2024 年大模型刚破圈流行的是提示词工程Prompt Engineering。怎么跟 AI 说话怎么让它听懂你的意思提示词写法变成显学。2025 年焦点转向上下文工程Context Engineering。不是怎么说而是喂什么信息。RAG、记忆系统、信息流怎么组织成了核心问题。站在 2026 年往回看两件事同时发生了大模型的基础能力越来越强同时 Agent 开始能自主执行多步骤的长任务。这两件事加在一起意味着需要一个技术框架能否让 Agent 在真实任务里稳定跑完。这就是 Harness 出现的原因它不是新鲜概念是从现实中自然发展出来的。02什么是 HarnessHarness 直译是马具/挽具。马本身有力量但是马具不提供动力它管方向、管节奏、管在极速状态下不翻车。一匹没有马具的马你坐不上去更别说让它按指定路线跑完全程。换到 AI 语境Agent 是马Harness 是马具。更工程化的定义Harness 是包裹在 AI 模型周围的基础设施专门用于管理长期任务。它不是 Agent 本身而是位于 Agent 框架之上的更高层架构提供预设上下文、工具调用的标准化处理、生命周期钩子以及开箱即用的能力比如规划、文件系统访问、子智能体管理。用操作系统方向类比Agent 是进程Harness 是内核调度系统。进程能做什么不完全由进程的代码决定——内存怎么分配、I/O 怎么调度、崩了怎么处理都是调度的事。没有调度的进程叫裸程序速度可能很快但能做的事极其有限而且一出错就什么都没了。Harness 解决的正是 Agent 版本的裸问题上下文长度有限、自我评估偏差、跨任务状态丢失、长任务中途失控这些不是模型能力问题是执行环境问题是工程问题。03业内案例一Anthropic这个案例起源于 Anthropic Labs 团队成员 Prithvi Rajasekaran的想法让 Claude 产出高质量的前端设计以及让它在没有人工干预的情况下构建完整的应用程序。对于这种复杂任务Agent 执行时会遇到两个常见的问题。上下文窗口因为冗长的任务填满而失去连贯性。一些模型还表现出上下文焦虑即当它们接近自己认为的上下文限制时开始过早结束工作。第二个问题是自我评估。被要求评估自己产出的工作时Agent 倾向于自信地赞扬这项工作而且这个问题在设计等主观任务中尤为突出。可能你也发现了在跟模型对话中它几乎都会给你正向的反馈于是作者编写了四个评分标准设计质量设计感觉是否像一个连贯的整体而不是部分的集合原创性是否有自定义决策的证据还是这是模板布局、库默认值和 AI 生成的模式工艺技术执行排版层次、间距一致性、色彩和谐、对比度。这是能力检查而不是创意检查。功能性独立于美学的可用性。用户能理解界面做什么、找到主要操作并在不猜测的情况下完成任务吗创意飞跃这种策略奏效了到第九次迭代它产出了一个虚构博物馆的干净、深色主题着陆页。页面视觉精致符合作者的期望。然后在第十次迭代Agent 完全废弃了这种方法给了作者从未见过的创意飞跃将网站重新想象为空间体验一个用 CSS 透视渲染的带有棋盘地板的 3D 房间艺术品以自由形式的位置挂在墙上基于门口的画廊房间之间导航而不是滚动或点击。扩展到全栈架构在前端项目获得成功后作者在原始 harness 的基础上构建了一个三个角色 Agent 系统。系统包含以下角色规划 Agent接受一个简单的 1-4 句提示并将其扩展为完整的产品规格。专注于产品上下文和高级技术设计而不是详细的技术实现。同时要求找到将 AI 功能嵌入到产品规划中的时机。生成 Agent以迭代方式工作一次从规格中挑选一个功能。每次迭代结束时自我评估其工作然后移交给 QA。使用 Git 用于版本控制。评估 Agent使用 Playwright MCP 像用户一样点击运行的应用程序测试 UI 功能、API 端点和数据库状态。然后它根据发现的 bug 和一组标准对每次迭代进行评分标准覆盖产品深度、功能性、视觉设计和代码质量。每个标准都有一个硬阈值如果任何一个低于它迭代就失败生成 Agent 就会得到关于出了什么问题的详细反馈。作者使用同一句提示词用于生成一个复古视频游戏制作工具跑了两种模式创建一款 2D 复古游戏制作工具其功能包括关卡编辑器、精灵编辑器、实体行为和可玩测试模式。模式时长成本结果单智能体20 分钟$9核心功能损坏游戏玩不了Harness6 小时$200功能完整的游戏制作器含 AI 辅助生成同一个提示词同一个基础模型差距来自执行环境。04业内案例二OpenAI从 2025 年 8 月开始OpenAI 进行一项实验构建并交付一款软件产品的内部 beta 版没有一行代码是人工编写的。人类掌舵。智能体执行。系统没有预存任何人工编写的代码。从一个空的 Git 仓库开始代码仓库就由智能体塑造。用 Codex CLI 在一小套现有模板的指导下生成了初始架构 — 包括代码仓库结构、CI 配置、格式化规则、包管理器设置和应用框架。五个月后该代码仓库已经拥有约一百万行代码从应用逻辑、基础设施、工具、文档到内部开发者工具应有尽有。到目前为止该产品已在数百名内测用户那里投入使用其中包括每天都在使用的内测高级用户。有意思的是随着开发团队从初始 3 人扩到 7 人吞吐量不降反升。人加多了系统反而更快。因为这里人的角色不是执行单元是系统设计者。多一个人不是多一双写代码的手是多一个能调优 Harness 的脑子。读下来类似在告诉 Agent 一个项目的标准流程SOP是怎么样的。而这正是我每天在做的事情告诉 Agent 某项工作的一套标准流程SOP然后让它自动化减少我在这项工作上所花费的时间。官方博客有一个细节单次 Codex 运行可以在一个任务上持续工作超过 6 小时。Agent 在跑工程师在睡觉早上起来 PR 已经在等待 review 了。代码仓库设为记录系统其中一个经验教训很简单要给 Agent 的是一张地图而不是一本 1,000 页的说明书。一份简短的 AGENTS.md大约 100 行被注入到上下文中主要用作地图并指向其他地方更深层次的真实信息来源。代码仓库内知识存储布局如下AGENTS.mdARCHITECTURE.mddocs/├── design-docs/│ ├── index.md│ ├── core-beliefs.md│ └── ...├── exec-plans/│ ├── active/│ ├── completed/│ └── tech-debt-tracker.md├── generated/│ └── db-schema.md├── product-specs/│ ├── index.md│ ├── new-user-onboarding.md│ └── ...├── references/│ ├── design-system-reference-llms.txt│ ├── nixpacks-llms.txt│ ├── uv-llms.txt│ └── ...├── DESIGN.md├── FRONTEND.md├── PLANS.md├── PRODUCT_SENSE.md├── QUALITY_SCORE.md├── RELIABILITY.md└── SECURITY.md意味着什么当 OpenAI 说代码库是由 Agent 生成的指的是整个代码库。产品代码与测试CI 配置和发布工具内部开发者工具文档和设计历史评估框架审阅评论和回复管理代码仓库本身的脚本生产仪表板定义文件人类还仍然参与其中但工作的层次与过去不同。工程师优先处理工作将用户反馈转化为验收标准并对结果进行验证。当 Agent 遇到困难时工程师将其视为一个信号识别缺失的内容 - 工具、指导与约束、文档 - 并将其反馈到代码仓库中始终由 Agent 自己编写修复。Agent.可以直接使用标准开发工具。它们会拉取审查反馈、在行内回复、推送更新并合并请求。05Harness 的四个核心组件一个有效的 Harness几乎都包含这四个部分。1. 多智能体架构把运动员和裁判分开单智能体方案失败有一个规律性原因让同一个 Agent 既生成又评估它会对自己的作品过度宽容。即使 Agent 生成了明显平庸的输出被要求评估时它仍然倾向于自信地赞扬这项工作。这不是 bug是 LLM 的结构性倾向——训练数据里人类对自己的作品都不会太苛刻模型学会了这个倾向。解法是把角色拆开。规划器、生成器、评估器三权分立。关键细节在评估器的调优。调优方式是读评估器的日志找它的判断和自己不一致的地方更新 QA 提示反复迭代直到严格程度符合预期。这个调优本身就是 Harness 工程师的核心工作之一。2. 上下文管理给地图不给说明书OpenAI 团队总结出一条经验给 Agent 的是一张地图而不是一本 1000 页的说明书。上下文是稀缺资源。一个塞满指令的 AGENTS.md 看起来很周全实际上挤掉了任务本身的空间。代码、测试结果、相关文档全都没地方放Agent 只好在信息缺失的情况下工作结果可想而知。更大的问题是一本厚手册会腐烂。Agent 无法判断里面哪些规则还有效、哪些已经过时。停止维护之后它就成为一个麻烦源头。解法是把 AGENTS.md 变成目录而不是百科全书。约 100 行主要是指针指向 docs/ 下面分类组织的真实知识库。如上文中展示的目录文件结构。Anthropic 则采用更技术的解法上下文重置。当 Agent 接近上下文窗口上限Harness 会完全清空对话历史。用结构化的交接文件把状态传给下一个 Agent 实例让它干净地接手工作。这和压缩不同压缩是把旧对话总结后继续Agent 还是同一个上下文窗口限制不会消失。重置是换了一个新 Agent状态通过文件传递干净地从零开始。3. 架构约束约束是加速器不是枷锁人类工程师在一个有严格分层约束的代码库里工作会感到迂腐。但 Agent 正好相反约束对 Agent 是加速器。原因是 Agent 无法像人一样凭经验感知这个代码放哪里合适。给它一个明确的规则代码只能按 Types → Config → Repo → Service → Runtime → UI 的方向依赖它就能立即、无偏差地执行而且每次都一样。OpenAI 把这些规则编进了自定义代码检查工具由 Codex 自己维护。工具错误信息里直接包含修复指令——不只是报错告诉 Agent 怎么改。当文档不够完善时我们会将规则转化为代码。这是一个工程哲学凡是可以被机械检查的规则就不要让 Agent凭感觉执行。能代码检查的就代码检查能测试的就测试能持续集成中拦截的就 集成拦截。4. 反馈回路让 Agent 能看到自己在做什么Agent 要能改进就需要能感知自己的输出效果。不只是代码编译通过而是这个功能用户点了之后到底有没有响应。OpenAI 的做法是让 Codex 能启动应用的独立实例通过 Chrome DevTools 协议与页面交互截图、DOM 快照、导航。这样 Agent 可以复现 bug、录制视频验证修复、用 LogQL 查日志用 PromQL 查指标。Anthropic 的评估器用 Playwright MCP 直接驱动浏览器像真实用户一样点击截图研究然后给出分数和具体的修改意见。把可观测的边界从代码扩展到运行时行为。Agent 不再是盲目执行而是能感知、能验证、能迭代。06从理论到代码DeerFlow 2.0国内的团队也在实践时发现了这个AI编程的趋势方向把这套规范做成了开源项目方便你上手实践这套开发理论框架。字节跳动的 DeerFlow 2.0刚发布就登上 GitHub Trending 第一目前 Star 数接近 50k。对照上面的四个组件看 DeerFlow 怎么实现的Harness 组件DeerFlow 对应实现多智能体架构Sub-Agents主智能体按需动态拉起子智能体每个有独立上下文和终止条件可并行执行上下文管理Context Engineering子智能体上下文完全隔离超长任务自动压缩并持久化中间结果架构约束Sandbox每个任务在 Docker 隔离容器里运行完整文件系统skills/workspace/uploads/outputs不同 Session 互不污染反馈回路长期记忆 可审计日志跨会话积累用户偏好、写作风格、技术栈Memory 保存在本地工具可扩展Skills Tools 可插拔内置研究/报告/幻灯片/网页生成等 Skills支持 MCP Server 和 Python 函数无限扩展值得单独说的是 Sandbox 这个设计。这个设计给 Agent 一台独立的电脑独立的文件系统、可以执行 Bash、可以读写文件、运行代码。但全程在 Docker 容器里隔离、可审计、任务完成后可以完整清除。在工程层面解决了 Agent 执行环境的安全和可重复性问题每次任务都在干净的环境里开始不用担心上一次任务的污染。一句话安装如果你在用 Claude Code、Codex、Cursor、Windsurf 或其他 coding agent可以直接把下面这句话发给它如果还没 clone DeerFlow就先 clone然后按照 https://raw.githubusercontent.com/bytedance/deer-flow/main/Install.md 把它的本地开发环境初始化好这条提示词是给 coding agent 用的。它会在需要时先 clone 仓库优先选择 Docker完成初始化并在结束时告诉你下一条启动命令以及还缺哪些配置需要你补充。快速启动如果是独立部署可以按官方推荐的 Docker 方式部署操作简单1. 从仓库复制代码git clone https://github.com/bytedance/deer-flow.gitcd deer-flow2. 生成配置基于模板make config3. 编辑 config.yaml配置你要使用的模型至少定义一个models: - name: gpt-4 display_name: GPT-4 use: langchain_openai:ChatOpenAI model: gpt-4 api_key: $OPENAI_API_KEY max_tokens: 4096 temperature: 0.74. 为已配置的模型设置API Key编辑项目根目录下 .env 文件TAVILY_API_KEYyour-tavily-api-keyOPENAI_API_KEYyour-openai-api-key5. 推荐Docker方式运行应用开发模式支持热更新挂载源码make docker-init # 拉取 sandbox 镜像首次运行或镜像更新时执行make docker-start # 启动服务会根据 config.yaml 自动判断 sandbox 模式生产模式一键启动本地构建镜像并挂载运行期配置与数据make up # 构建镜像并启动全部生产服务make down # 停止并移除容器6. 访问 http://localhost:2026完成。IM 社交平台支持我猜这项功能应该是受 OpenClaw 的启发DeerFlow 支持从即时通讯应用接收任务。只要配置完成对应渠道会自动启动而且都不需要公网 IP。目前官方支持TelegramSlackFeishuLark。以飞书为例1. 在 config.yaml 中配置飞书频道可用。channels: feishu: enabled: true app_id: $FEISHU_APP_ID app_secret: $FEISHU_APP_SECRET2. 在飞书开放平台 创建应用并启用 Bot 能力。3. 添加权限im:message、im:message.p2p_msg:readonly、im:resource。4. 在事件订阅 中订阅 im.message.receive_v1连接方式选择 长连接。5. 复制 App ID 和 App Secret在 .env 中设置 FEISHU_APP_ID 和 FEISHU_APP_SECRET并在 config.yaml 中启用该渠道。渠道连接完成后你便可以直接在聊天窗口里和 DeerFlow 交互。Sub-Agents 子智能体值得说明的是DeerFlow 内置了子智能体系统使得你可以像指挥团队一样拥有一支 7*24 小时的数字员工团队。复杂任务通常不可能一次完成DeerFlow 会先拆解再执行。lead agent 领导智能体 可以按需动态拉起 sub-agents 子智能体。每个 sub-agent 都有自己独立的上下文、工具和终止条件。只要条件允许它们就会并行运行返回结构化结果最后再由 lead agent 汇总成一份完整输出。这也是 DeerFlow 能处理从几分钟到几小时任务的原因。比如一个研究任务可以拆成十几个 sub-agents分别探索不同方向。最后合并成一份报告或者一个网站或者一套带生成视觉内容的演示文稿。一个 harness多路并行。07Harness 工程师在做什么Harness 是一套 AI 编程理念在不同技术团队工程实现上可能有差别但核心思想是同一件事工程师的工作从写代码迁移到了设计执行环境。这个迁移不是减法。工程师没有被取代是被推到了更高的抽象层- 以前把需求翻译成函数- 现在把意图变成可执行的验收标准把规则变成可以检查代码的约束把人类经验变成 Agent 能读取的知识库当事情进展不顺利解决方案再也不是再努力一点。因为取得进展的唯一方式是让 Agent 来完成工作人类工程师的任务是追问还缺什么能力怎么让这个能力对 Agent 既可读又可强制执行越大的系统越不能靠个人能力撑靠的是流程、约束和反馈机制。到了几百人的工程组织架构规范和持续集成的检查比任何一个10倍效率 工程师都重要。Harness 把这个道理平移到了 Agent 上。Agent 越强能力边界越高Harness 里有意思的工程问题不会变少只会往更复杂的方向移动。有趣的是 Harness 组合的空间不会随着模型改进而缩小。相反它会扩大。模型越强能接的任务越复杂任务越复杂执行环境出错的概率越高需要的编排越精细。一个能做500步任务的AgentHarness设计不好就是一场500步之后的灾难。这和操作系统的历史一样CPU越来越快调度问题不是消失了是变得更复杂多核、实时性、能耗全是新的调度课题。所以 Harness 工程师不是一个过渡期职业。模型每进化一代这个岗位的有趣程度就往上走一级。08最后刷到过一个刚入职创业公司的博主的视频。他说老板交代了一项任务问他需要多久。他回答我需要先调研一下然后根据调研的结果再规划任务和评估时间。老板说你不应该还按以前人来做事的思路去做应该做一个 Agent 然后考虑怎么让 Agent 完成任务。规则只变了一条赢的不再是写最多代码的人而是为 Agent 造出最好赛场的人。为什么都是围绕 Agent 去做这么多工作和改变因为它是提升工作效率的核心所有一切都必须围绕这个核心来运转。有人焦虑AI来了怎么办在我之前的文章有过观察《AI 会替代程序员吗Anthropic 内部使用 Claude Code 的使用调查》和思考《AI时代的职业重构并非零和游戏》。你现在怎么用 Agent 评论区聊聊尤其是踩过的坑比成功案例有用得多。-END--推荐阅读效率提升 10 倍OpenClaw OpenCLI 实战体验让OpenClaw替你打工五没花什么钱养了6只虾还赚到了钱Google 开源实战指南21种AI智能体设计模式覆盖从基础到安全的完整体系OpenClaw Obsidian最小成本搭建 AI 记忆同步系统OpenClaw 为什么总“失忆”双层记忆 三层防御让它真正记住你给 OpenClaw 接入10000工具和数据为你盯盘给出独家策略让你的OpenClaw替你打工从0到1跑通小红书运营全流程实战教程谷歌提示工程白皮书Google Prompt Engineering White-paperSkill设计白皮书Anthropic官方推荐的构建方法与避坑指南