自建编码代理总是失败?真正的差距在Harness而非底层模型

📅 2026/7/16 8:12:41
自建编码代理总是失败?真正的差距在Harness而非底层模型
你尝试过自己搭建编码代理吗把模型连上文件工具和Shell扔给一个真实代码库通常十几步工具调用后就崩了读错文件、忘记初始目标、上下文被无用输出塞满。而同样的任务交给 Claude Code却能干净利落地完成。很多人第一反应是“Anthropic的模型更强”。这个结论错过了真正的工作发生在哪里。差距不在模型而在Harness代理线束。Harness 是包裹在模型外层的普通代码负责规划、工具执行、记忆管理、安全控制和编排而模型只负责“下一步该做什么”。Anthropic 把这个分工描述为“大脑与双手”模型是大脑Harness 是执行并保持任务在轨的双手。下面我们把 Harness 完整拆解成可落地的层级并用 CrewAI 这个开源框架一步步复现标明哪些是框架免费提供的哪些 still 需要你自己工程化。Harness 的核心构成一个完整的生产级编码代理 Harness 可以拆成四个主要部分Memory为模型提供当前工作上下文 跨会话学到的知识Skills编码代理应遵循的流程、约束和启发式规则Protocols连接用户、工具和其他代理的接口Harness Core把一切串起来的核心包括子代理编排、沙箱、评估器、审批循环、可观测性和上下文压缩Claude Code 正是用这套相对完整的 Harness 实现了可靠的编码能力。下面我们从最底层的执行循环开始一层一层往上叠加。第一层核心执行循环CrewAI 免费提供最底层的循环极其简单把任务发给模型模型要么直接回复要么请求一个或多个工具执行工具把结果塞回对话重复直到模型不再请求工具并给出最终答案这个循环本身就能让模型读文件、改代码、跑 Shell、执行测试。但纯循环很容易目标漂移、上下文爆炸。CrewAI 实现创建一个 Agent Task Crew调用kickoff()就自动跑起这个循环。你不需要自己写 while 循环。fromcrewaiimportAgent,Crew,Task bug_fixerAgent(roleBug Fixer,goal修复代码库中的失败测试,llmLLM(modelanthropic/claude-sonnet-4.6),tools[file_read,file_write,shell_exec])taskTask(description在 ./workspace 中修复 account.py 的失败测试,expected_output修改摘要 最终测试结果)crewCrew(agents[bug_fixer],tasks[task])resultcrew.kickoff()框架把“决定-执行-反馈”循环完全封装了。第二层工具系统CrewAI 提供基础特定需求需自定义模型本身只会生成文本工具让它真正“动手”。CrewAI 内置文件系统工具FileReadTool、DirectoryReadTool、FileWriterTool这些工具还能充当外部记忆把大段搜索结果写进文件只在上下文中保留文件名需要时再读回来这就是 Anthropic 说的context engineering。自定义工具用tool装饰器docstring 就是给模型的说明书。第三层规划Planning——对抗上下文腐烂长任务执行十几二十步后原始目标很容易被中间结果淹没context rot。解决方案是让代理先输出一个 step-by-step 计划并在整个执行过程中把计划留在上下文中。CrewAI 实现crewCrew(...,planningTrue)# 任务级规划agentAgent(...,reasoningTrue)# 单个代理的深度推理规划负责全局路线图reasoning 负责代理内部的思考-评估-精炼循环。两者结合能显著减少目标漂移。第四层子代理与层级编排Subagents大型代码库修复可能需要读几十个文件主代理不需要把所有中间结果都塞进自己的上下文。做法是委托主代理把具体任务分给专业子代理子代理在自己的上下文中完成工作只返回简短结论。CrewAI 实现开启allow_delegationTrueProcess.hierarchical并指定manager_agent。示例拆分Codebase Explorer探索仓库Software Engineer实现修改Test Runner在沙箱跑测试Engineering Lead经理代理负责委托与汇总第五层安全Sandbox 人工审批再强的提示词也挡不住模型执行危险命令。真正的安全来自两层机制权限系统敏感操作必须人工审批沙箱隔离即使批准命令也只能在隔离环境执行CrewAI 实现使用 E2B 等沙箱工具把 Shell 和 Python 执行完全隔离在临时 VM 中Task 上设置human_inputTrue任务生成答案后暂停等待人工 review第六层记忆与检查点Memory Checkpoint默认情况下代理跑完一次就忘得一干二净。Memory跨会话持久化事实如“项目偏好最终代码必须格式化”Checkpoint保存运行时状态支持中断后恢复CrewAI 实现crewCrew(agents[...],tasks[...],memoryTrue,# 跨运行记忆checkpointTrue# 运行时检查点)记忆由 LLM 自动提炼重要信息并检索检查点可存 JSON 或 SQLite。完整 Harness 在一个 Bug Fix 任务上的效果把上面六层全部打开对一个包含真实 Bug 的 BankAccount 类5 个测试初始 3 失败 2 通过进行测试。规则是只能修改实现不能改测试本身。结果Harness 成功把所有测试修复通过。这与 Anthropic 内部评估编码代理的方式高度一致——用真实失败测试套件作为客观衡量标准。框架能给你什么、不能给你什么框架免费提供执行循环工具调用机制规划与推理子代理委托沙箱集成记忆与检查点仍需你自己工程化每个 Agent 的 role/goal/backstory 提示词需要反复迭代执行环境搭建沙箱配置工具选择与权限分配成本控制规划 子代理会增加 API 调用此外要记住随着模型能力提升部分今天必须的 Harness scaffolding 未来可能会变得多余。Anthropic 自己就曾因为模型升级而移除了某些上下文重置机制。系统级判断起初很多人包括我以为“只要模型够强简单接工具就能做出可靠编码代理”。在用 CrewAI 完整复现 Harness 各层后才发现模型只是大脑真正决定成败的是“双手”——规划、记忆、安全、编排这些工程层。Harness 不是临时补丁而是目前让编码代理从“玩具”变成“生产工具”的核心工程工作。在你的代码库上真正落地前建议从一个极小的 Bug Fix 任务开始只开 planning memory sandbox human_input观察上下文长度、成功率和成本变化再逐步叠加子代理。当模型继续变强时Harness 的设计会越来越像“最小必要 scaffolding”而不是越来越复杂。你目前在构建或评估编码代理时遇到的最大瓶颈是上下文管理、目标漂移还是安全审批我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。