再次聊聊AI Coding对应的 Harness Engineering 的6 大支柱及其在 Coding 中的映射与部分实践

Harness Engineering 的 6 大支柱

无论是agent自身的Harness Engineering ，还是AI coding对应的Harness Engineering都有这几个方面：

• 方面一：上下文管理（Context Architecture）
• 方面二：工具系统（Tool System）
• 方面三：执行编排与多 Agent 协作（Execution Orchestration）
• 方面四：状态与记忆（State & Memory）
• 方面五：评估与观测（Evaluation & Observability）
• 方面六：约束与恢复（Guardrails & Recovery）

这次只聊聊AI coding对应的Harness Engineering这几方面的映射实践。

方面一：上下文管理

对agent上下文管理来说更多指的是在llm有限的上下文窗口中更好的留下有用有价值的信息。

在AI coding中这方面指的更多的是，如何提供给AI更好的工程信息，需求信息等信息。

在实践中更多是这样的：

构建自己的AI Agent心得

折腾了一段时间AI Agent开发，从最初调API写demo，到后来用LangChain搭workflow，再到最后决定自己撸一个轻量框架——这篇文章算是把踩过的坑和想明白的事儿做个总结。如果你也是那种”用别人的框架总觉得哪里不对劲”的开发者，这篇可能对你有点用。

具体代码参考： https://github.com/sunyanyan/learn-ai-agent

为何需要自建Agent框架

先说一个最根本的问题：LLM和Agent到底是什么关系？

尝试一下用ai开始全新的领域，完全用ai写一个游戏，自己不主动修改任意一行代码。遇到了一些问题，最终还是写出了一个小demo mvp,题材为卡牌肉鸽游戏：

一、我是怎么一步步发现问题的

我一开始以为，AI 辅助开发游戏这件事，关键只是把需求说清楚。

Harness Engineering 是围绕 AI Agent 设计约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。它解决的核心问题是：当 AI Agent 拥有了强大的代码生成能力后，如何确保其输出的可靠性、一致性和长期可维护性。

引言：三层工程概念的嵌套关系

Prompt Engineering、Context Engineering 和 Harness Engineering 构成了嵌套关系，而非并列概念。Phil Schmid 打了个比方：模型是 CPU，Harness 是操作系统——CPU 再强，OS 拉胯也白搭。

Prompt Engineering 解决的是”如何与模型对话”：如何编写清晰的指令、如何设计 Few-shot 示例、如何使用 Chain-of-Thought 推理。它是原子层面的交互优化。

Context Engineering 解决的是”给 Agent 看什么”：如何组织上下文窗口、如何检索相关信息、如何管理对话历史。它是会话层面的信息管理。

Harness Engineering 解决的是”系统怎么防崩、怎么量化、怎么修”：如何构建多协作系统、如何设计反馈回路、如何强制执行架构约束。它是系统层面的工程实践。

三者层层递进：Prompt Engineering 是基础，Context Engineering 在其之上构建会话管理，Harness Engineering 在更上层构建完整的开发和运维体系。mtrajan 的区分更直接：Context Engineering 管的是输入，Harness Engineering 管的是系统行为。

PDCA（Plan-Do-Check-Act）是戴明提出的持续改进闭环，核心思想是让每轮循环都比上一轮更聪明。复利工程把这个思想搬进 AI 编码时代：AI 不只是写代码的工具，更是把每次开发的知识固化下来的载体，让每一次工作都站在上一次的积累上。

AI 代替人写代码，这件事已经发生了。但大多数人的用法停留在「给 AI 一个需求，拿回一段代码」。这种用法有个隐患：代码在变多，但对代码库的理解没有同步增长——知识存在人脑里，人会忘、会离职，下一个人仍然踩同样的坑。

传统 PDCA 在软件工程里卡在「Act」这步。问题找到了，就是没人把改进固化成规则让所有人用上。AI 的出现让这件事的成本接近零：让 AI 总结一次 Review、写几条规则进文件，30 秒。这就是复利工程想做的事。

OpenCode 提供了一套基于 TypeScript 的插件系统，允许开发者为 AI 编码助手注入自定义工具。本文通过一个实际的 Benchmark 插件，拆解 OpenCode 插件的开发原理、核心 API 和最佳实践。

引言：为什么要给 AI 编码助手写插件

AI 编码工具已经成为日常开发的一部分。但每个团队的工作流都有差异——有人需要对接内部服务，有人需要自定义代码检查，有人需要测量不同模型的响应速度。通用的 AI 助手不可能覆盖所有场景。

OpenCode 的解决方案是开放插件系统：你可以用 TypeScript 编写插件，注册自定义工具（Tool），这些工具直接暴露给 AI Agent 调用。当你在对话中说”帮我跑一下模型基准测试”，AI 就会调用你写的 benchmark_models 工具，而不是猜测或拒绝。

这篇文章分两部分：先讲 OpenCode 插件的运行原理，再用一个 Benchmark 插件的完整实现说明怎么从零开始写一个插件。

背景：OpenCode 的扩展体系

OpenCode 是一个终端内运行的 AI 编码助手，支持多种 LLM 提供商（OpenAI、Anthropic、Google 等）。它的扩展体系有两个核心概念：

• Plugin（插件）：TypeScript 代码，运行在 OpenCode 进程中，注册自定义工具和生命周期钩子。AI Agent 可以像调用内置工具一样调用插件注册的工具。
• Skill（技能）：纯 Markdown 文件（SKILL.md），不包含可执行代码，通过自然语言指令影响 AI Agent 的行为模式。技能告诉 AI”在什么场景下使用什么工具、如何使用”。

两者配合使用：Plugin 提供能力（Tool），Skill 提供策略（When & How）。

如何将 SDD（规范驱动开发）的结构化工作流与多智能体并行编排深度融合，在 AI 辅助编码中同时实现高吞吐与高可靠。

一、引言：AI 编码的效率天花板

2025 年以来，AI 辅助编码已经从”补全一行代码”进化到”端到端实现一个功能”。行业数据令人振奋——Atlassian 在全面采用 AI Agent 后测量到工程师人均 PR 数量提升了 89%；Stripe 的 Agent 系统每周自主合并超过 1000 个 PR；Rakuten 利用 AI Agent 在 7 小时内完成了 1250 万行代码库上的复杂 vLLM 实现。

但随着 AI Agent 承担的任务从单文件修改扩展到跨模块的复杂变更，一个新的瓶颈开始浮现：

单智能体顺序执行的效率天花板。

想象一下这个场景：你要给项目新增一个用户认证模块。这涉及数据模型、API 端点、中间件、前端集成和测试——至少 5-6 个相互关联的子任务。在传统的单 Agent 模式下，即便这些任务中有些彼此独立，AI 也只能一个接一个地串行执行。5 个任务各花 5 分钟，总耗时就是 25 分钟。

更致命的是质量问题。单 Agent 既当运动员又当裁判：自己写的代码自己验证，缺少独立的质量门控。研究表明，多智能体系统中 13.2% 的失败来自推理-动作不匹配，7.4% 来自任务偏离，6.8% 来自错误假设。当 Agent 对某个 API 不确定时，它可能会猜测类型、留下 TODO、甚至抑制类型检查——这些”半成品”在复杂项目中会迅速积累成技术债务。

微软研究院将 “意图形式化”（Intent Formalization） 定义为可靠 AI 编码的核心挑战——如何自动将模糊的人类意图转化为精确、可检查的规范。这恰恰是 SDD（规范驱动开发）试图解决的问题。

这驱使我们思考两个核心问题：

1. 能不能让多个 AI 智能体并行工作，像流水线一样同时处理互不依赖的任务？
2. 能不能在 AI 执行链路中嵌入结构化的质量门控，让”写代码”和”验代码”由不同的角色完成？

OMO-OPSX 正是对这两个问题的回答。它将 OpenSpec 的规范驱动开发（SDD）工作流与 OMO（oh-my-opencode） 的多智能体编排能力深度融合，在保持开发灵活性的前提下，实现并行加速与分层质量保障。这种融合代表了一种正在兴起的工程范式——有人称之为**”复合工程”（Compound Engineering）**：工程师的角色从”代码编写者”转变为”系统编排者”，通过设计约束、编排智能体和验证输出来实现 3-7 倍的生产力提升。

掌握这六大策略，让你的提示词更高效，让 GPT-4 等 AI 模型输出更精准、更符合预期的结果。

iOS页面路由,具体可能需要处理的场景、问题有：

1. 最普通 原生页面跳转到原生页面
2. 有多种技术栈的app，可能包含原生、h5/rn/flutter等页面。就扩展出：
   • 原生页面和h5页面互相跳转
   • 原生和rn页面互相跳转
   • 原生和flutter互相跳转等
3. 在上述的基础上，很多原本原生实现的页面，需要通过新的H5页面进行升级/降级，或者原本PC或者H5页面，需要重定向到已有的原生页面。而这些基本都是硬编码的跳转逻辑，需要随着版本不停改动。跳转的逻辑需要根据版本迭代走，无法统一远程进行改动（例如：每次新增一个需要拦截跳转原生的页面，都需要通过发版来解决）
   • 跨技术栈跳转的实现成本比较高，必须在桥接模块中进行特殊适配。H5页面中，某些跳转需要跳转原生或者其他页面，必须要通过WebView跳转的拦截做特殊判断处理
   • 需要梳理的各技术栈跳转逻辑，将这些跳转整合，能够满足动态性、可配置的需求。
4. 一些应用有社交分享功能，需要分享出去一个链接以打开自身app内特定页面。或者有应用内分享链接 也可以打开自身app内特定页面。
   • 一般来说 应用外打开app需要使用iOS的URL Scheme功能或者Universal links功能

探究一下我们计算app储存空间的大小时和系统设置里的差距

App自身大小差距

系统设置里App的存储空间分为：“App大小”和“文稿与数据”。