建议 1。从线性 while 循环开始；只有当正交的轮次级策略出现时才升级为中间件管线。证据：观察 5（循环的精巧程度不能预测基准表现）；Mini-SWE-Agent 的 50 行线性循环在 SWE-Bench Verified 上报告 74%+（自报；见表 4 脚注）。升级路径：一旦你需要三个或以上相互独立的轮次级策略（轮次上限、成本上限、自动压缩、上下文预算警告、只读模式），采用 Mistral Vibe 的中间件管线模式——每个策略成为一个可组合的中间件，而不是循环体里一个新分支。

建议 2。如果你自己也出货基础模型，就与自家供应商紧耦合，并暴露一个通用回退适配器以保证可移植性；如果你不出货，厂商原生的优化仍可争取——把预算花在逐模型元数据上。证据：观察 7.1。Mistral Vibe 的“供应商优先 + 通用回退”仍是厂商模式。对多供应商 Harness 而言，Pi 的逐模型 compat 怪癖旗标、Hermes 的声明式供应商档案、OpenCode 的转换矩阵表明：缓存断点、思考档位与推理力度从抽象层也可触及——代价是一个需要持续维护的逐供应商条件化层，集中付一次。

建议 3。先只配一个 bash 工具。只在观察到失败模式时才增加更多工具。证据：Mini-SWE-Agent 的单工具设计在几乎没有工具基础设施的情况下于 SWE-Bench 报告 74%+（自报）；Aizawa 等人 [18] 提醒“工具更多并不总是带来更好结果”。常见顺序是：当 bash 输出截断成为问题时加 read_file 与 write_file；当 bash+find/rg 用着别扭时加 grep/glob；当整文件重写浪费 token 时加 search_replace。

建议 4。当工具数超过约 $\sim$15 时，采用工具延迟加载。证据：Claude Code 的 shouldDefer 旗标 + ToolSearchTool 把初始提示词削减约 $\sim$40%；Codex 独立收敛到 defer_loading 旗标加 BM25 排序的 tool_search；Hermes 在 schema 将超过上下文窗口 10% 时，把溢出的 MCP 目录折叠成三个 BM25 检索的桥接工具。低于约 $\sim$15 个工具，间接层不值得那点复杂度；高于它，提示词膨胀就变得不可承受。

建议 5。让编辑工具契约匹配你的模型档位：前沿模型用精确唯一子串替换，开放或较弱的模型用模糊级联——无论哪种，都在工具内处理漂移，绝不靠行号。证据：观察 8.4。前沿模型阵营已收敛到精确契约（Claude Code；Mistral Vibe 删除了 SEARCH/REPLACE 工具并于 2026 年年中收敛到精确匹配；Pi 只加 Unicode/空白规范化与字节保真叠加）。容忍漂移的阵营服务更宽的模型范围（OpenCode 在 Levenshtein 0.65 下的九阶段级联、Hermes 的九策略链、Aider 的 RelativeIndenter）。Gemini CLI 的 LLM 编辑修复器子调用是浮现中的第三条路：用模型而非阈值修复匹配。避免基于行号的编辑：模型在行号上的漂移大于在上下文匹配上的漂移。

建议 6。在项目、用户与扩展作用域自动发现分层的 Markdown 上下文文件——也顺便读读邻居们的文件名。证据：全部 11 个管理仓库上下文的系统都收敛到该模式，最新的几个读多种约定（Hermes：自家文件，然后 AGENTS.md、CLAUDE.md、.cursorrules；OpenCode：AGENTS.md/CLAUDE.md/CONTEXT.md 加远程 URL；OpenHands 把三个生态的文件摄入为带作用域规则）。把顶层内容注入系统提示词顶部附近，当工具触及其子树时即时浮现嵌套文件（Mistral Vibe、OpenCode、Hermes、Gemini CLI），并让模型持久化持久事实——经直接编辑、有界快照文件或人工审查的收件箱（观察 9.6）。

建议 7。在模型上下文窗口下方固定缓冲处实现阈值压缩；逐字保留最近的尾部；增量合并摘要而非从零重摘；并把同一例程接到溢出时响应式触发。证据：Claude Code 在 13K token 缓冲之下触发并压缩后恢复文件；Gemini CLI 在 50% 处压缩并保留最近 30%；Pi 与 OpenCode 把上一个摘要传回合并（锚定/迭代式摘要），保住了从零重摘会丢失的早期决策；Mistral Vibe 把先前的用户消息重新注入压缩信封，并在轮次中途 ContextTooLong 错误时复用同一例程；OpenHands 把溢出错误路由进压缩。激进压缩防上下文腐坏 [19]；保守保留让近期推理保持连贯。

建议 8。不要在代码上建 RAG。改用 ripgrep、glob、tree-sitter 符号抽取与文件系统遍历。证据：观察 13.2；0/11 系统用向量嵌入做代码检索；Rajasekaran 等人 [19] 在实践中偏好 JIT 检索，其全部具体建议都指向确定性工具。代码拥有语义相似度无法复制的丰富确定性结构（路径、语言服务器、tree-sitter 解析），而且每分钟都在变，嵌入随即过时。

建议 9。对开发者工具（半可信）场景：实现带权限作用域模式的三模式审批系统（PLAN / DEFAULT / YOLO）。证据：Gemini CLI 的 PLAN/DEFAULT/YOLO 模式、Mistral Vibe 的 4 层权限层级（工具级 + 工具专属 + 会话规则 + 交互回调）；这与人类开发者给风险分诊的方式吻合。

建议 10。对企业 / 共享 / 自动化场景：实现操作系统级沙箱，配策略即代码与逐智能体审计轨迹。证据：观察 10.2；Codex 与 Gemini CLI 出货原生跨平台沙箱（Linux 上 Bubblewrap——Codex 的情况下为 vendored——macOS 上 Seatbelt、Windows 上受限令牌），Claude Code 把 Anthropic 可复用的 sandbox-runtime 包成可选件。Gemini CLI 的实现表明：只要复用操作系统二进制（Node child_process 或等价物）而非从零写命名空间管线，成本是可容忍的。

建议 11。无论哪一档，把安全规则编码为数据或专门策略文件，而非命令式代码——而且如果你支持 YOLO 模式，在它下面保留一道底线。证据：Codex 的 Starlark execpolicy 规则带解析时校验的内联示例、Claude Code 的 PreToolUse Hook、Gemini CLI 的分模式 TOML、OpenCode 的后匹配胜出规则集。Hermes 补上了底线教训：它的 12 个硬性模式在 --yolo 下仍存活，绕过旗标在模块导入时被冻结，注入内容无法在运行时翻转它。策略即代码能在重构中幸存，且独立于循环实现可审计。

建议 12。保持单智能体，直到你能指出一个具体的广度优先探索阶段——并行上下文隔离明显胜过串行检索的阶段。证据：Hadfield 等人 [17] 提醒多智能体系统比聊天基线多耗约 $\sim$15$\times$ token，且“多数编码任务中真正可并行的任务比研究少”；Mistral Vibe 的 task 工具委派子智能体（其提示词鼓励并行启动多个），对多数编码工作流已足够。

建议 13。出货一个 ACP 服务器：它已不只是编辑器集成——它让你的 Harness 可被宿主与元编排者消费。把自己的子智能体留在进程内。证据：观察 13.3。一台 ACP 服务器如今一次买来三类受众：IDE（Zed、JetBrains）、托管 Harness（OpenHands 把 Claude Code/Codex/Gemini CLI 作为可互换的 ACP 后端运行）、元 Harness（Omnigent 经 ACP 驱动 Goose 与 Qwen）。语料库 11 个系统中有 6 个出货。对智能体 $\leftrightarrow$ 智能体的网格拓扑，A2A 仍只是 Gemini CLI 一个人的押注——可辩护，未经验证。对自己运行时之内的主智能体 $\leftrightarrow$ 子智能体协调，不要采用其中任何一个（见建议 12）：进程内原语才是生产级系统用的，连跨进程的例外（Pi 的 JSONL 扩展、Hermes 的 SQLite 黑板集群）都为该角色避开标准协议。

建议 14。把技能用于能力模板（工作流、领域知识、过程性配方），把 MCP 用于外部集成（Slack、数据库、内部 API）——按这个优先顺序。证据：观察 12.5：技能的采用率现已领先 MCP（9/11 对 8/11），发现机制是跨厂商的（OpenCode 读 ~/.claude/skills），分发已有注册表与来源验证。MCP 仍是运行外部进程的正确层；Pi 演示了可辩护的极简立场（技能加带 README 的 CLI 工具，不要 MCP）。若安装第三方技能，把它们当包对待：信任分级、扫描与隔离区（Hermes）是浮现中的基线 [89]。

建议 15。不要把 LangChain、LangGraph、AutoGen、CrewAI、LlamaIndex、Pydantic AI、Genkit、Google ADK 或 Semantic Kernel 用于智能体运行时。证据：观察 13.2；语料库中 0/11 生产级 Harness 使用这些框架——Gemini CLI 连 Google 自家的都跳过。Schluntz 与 Zhang [16] 明确警告：“框架常常制造额外的抽象层，遮蔽底层的提示词与响应，使它们更难调试。”用原始 SDK 调用——或者，2026 年的推论（第 14.2 节）：如果你想要一个带电池的起点，Harness SDK（Claude Agent SDK、openai-codex、openhands-sdk）就是如今的框架层，语料库的模式内建其中。

建议 16。不要为代码构建向量嵌入检索层。证据：观察 13.2；0/11 系统这样做。出现的嵌入服务于会话记忆（OpenClaw 的默认混合检索；Hermes 的可选插件），而 Hermes 表明词法 SQLite FTS5 在 64.2 万行规模上对该角色已足够。如果你确信你的领域需要语义代码检索，先在一组留出任务上证明它优于 ripgrep+tree-sitter，再上基础设施。

建议 17。不要把每个上游 SaaS API 都包成一对一工具。证据：Aizawa 等人 [18]；“我们观察到的常见错误，是工具仅仅包装既有软件功能或 API 端点。”要合并，不要复制。

建议 18。不要把卡死检测过度工程化——但要把那些便宜的上限发出去，它们只花十几行代码。证据：Claude Code 与 Codex 至今不带自动化卡死检测，仍交付生产级智能体。不过地板在动：连 Mini-SWE-Agent 都已限制连续畸形响应与真实时钟，OpenCode 的死循环检查是一个路由到权限询问的三次相同调用计数器，Hermes 对调用签名做哈希但把硬停止默认关闭、信任警告。OpenHands 的五场景 StuckDetector 与 Gemini CLI 的哈希+LLM 混合服务仍是平台级的投入。

作为具体起点，清单 3 用约 $\sim$90 行 Python 勾勒一个最小可用 Harness，组合了上文推荐的模式：线性循环（Mini-SWE-Agent）、中间件式策略（Mistral Vibe）、四工具表面（bash、read、write、search_replace）、分层 Markdown 上下文自动发现（全部四个厂商原生系统）、阈值压缩（Claude Code/Gemini CLI/Mistral Vibe）。 它不是拿来即用的库；它是供复制与特化的脚手架。

上面的脚手架刻意省略了语料库显示存在分歧的特性：沙箱（建议 9–10 依部署场景而定）、多智能体（建议 12 推迟它）、MCP/技能（建议 14 属于可扩展性而非核心）。 从这里出发，度量 [17]，只加上你观察到的失败模式所要求的最小集合。

观察 13。清单 3 的 90 行最小可用智能体直接实现了 18 条建议中的 10 条，并与其余 8 条兼容。它做到这一点，不依赖任何框架、没有 RAG、没有向量库、没有多智能体编排、也没有沙箱——与双重缺席（观察 13.2）和 [16] 的“从简单开始”原则吻合。我们未经证明地猜想：这个脚手架跑在前沿模型上，可以达到 Mini-SWE-Agent 的 SWE-Bench 水平；而要超越这些数字，主要是一个模型能力问题（观察 5），而非脚手架问题。