Agent Harness 设计指南：Coding Agent 实践

一个 Agent 由两部分组成：模型，以及模型之外的一切——Harness。本文从一句最简单的对话出发，拆解 Agent 从代码到 next token 的完整链路，再依次讨论 Context、Memory、Long-Horizon、Multi-Agent 四个方向的设计取舍，最后讨论如何通过评测与生产反馈让 Harness 和模型持续进步。

全文围绕三个问题展开：

三个问题层层递进：先看清机制，否则设计决策只能凭感觉；再基于机制做出取舍；最后用评测判断改得对不对。

核心观点

1. Agent = Model + Harness。 模型只做一件事：根据已有内容预测 next token。工具执行、上下文组织、状态管理、调度与评测，模型之外的一切都是 Harness。
2. 能力在模型，Harness 负责释放与对齐。 Harness 不创造智能，它决定模型的能力能发挥出多少，以及是否用在正确的方向上。
3. Context Engineering 是 Harness 的核心工作。 每次生成前，提供刚好足以支撑下一步行动的上下文：能力按需加载，上下文 append-only 以命中 prefix cache，窗口吃紧时由模型主动压缩。
4. 记忆走”简单架构 + 依赖模型进步”的路线。 目录树 + Markdown + BM25/grep，画像常驻、经验渐进加载；评测的是带记忆的 Agent 在真实任务上的成功率与 token 消耗，而不只是记忆问答分数。
5. 长程任务靠两个支点： Harness 工程的稳定性，以及长时间的目标保持（目标压缩 + 状态 offload 到磁盘）。
6. Multi-Agent 的瓶颈在模型的协作能力， Harness 负责提供状态、消息与交接接口。
7. 持续改进是一个闭环： 生产执行 → Harness 验证与演进 → 模型能力内化 → 更强模型与新场景。Harness 改进先回到生产，可迁移的能力再通过训练进入模型。

知乎话题总结：2026 年 OPC（一人公司）为什么不再是口号？

整理时间：2026-06-26
问题链接：https://www.zhihu.com/question/2030748379056190158
原始回答链接：https://www.zhihu.com/question/2030748379056190158/answer/2053773797631775981

读取范围

这次使用已登录知乎的内置浏览器读取，范围比上一版大很多。

• 问题页显示：951 个回答，163 个回答被折叠。
• 默认排序页：读取到页面直接展示的 5 条核心回答。
• 按时间排序页：从 2026-06-26 13:58 往前滚动读取到 2026-04-28 23:05，共保存 270 条回答。
• 本地原始采集文件：/Users/wyan/Downloads/zhihu_opc_time_answers.json

注意：本文档不是 951 条全量逐条复述，而是基于已读取的 270 条时间序回答和默认排序高赞回答做主题归纳、赞同数排序和判断。未读取部分主要是更早时间的回答、折叠回答，以及知乎未继续加载出的内容。

背景：需求澄清是一个被低估的成本中心

做过研发的人都知道，需求评审会结束后，研发真正动手写代码，往往还要经历一轮”追着产品问”的过程。这些问题有时候很小（一个按钮文案），有时候很大（整个业务逻辑是否成立）。问题问得晚，代价是已经写了一半的代码要返工；问题没问到，代价是上线后出 bug 或功能偏差。

我们在 Codelix 中尝试用 AI 来解决这个问题。本文记录了从立项到多轮迭代的全过程，包括遇到的坑、做的取舍，以及最终效果。

背景

Codelix 最初是为后台服务设计的 AI 编码平台：给一个 TAPD 需求单，AI 自动完成需求分析、方案设计、代码生成、编译校验、Code Review 全流水线。后台场景相对规整，踩坑踩了几个月后，我们开始把这套流水线推广到 iOS、Android、Kuikly 三个客户端平台。

这篇文章记录了整个过程的技术细节，包括 iOS pipeline 从零到可用，Kuikly 接入时踩的低级 bug，Android 的广撒网问题，以及跨三端做统一优化的五轮演进。

前言

从最早思考《为什么要做一个 iOS bug 自动修复的 agent 程序》，到 V3 把单文件原型重构成 AgentEngine 引擎、V4 把领域知识结构化、V5 把「完成需求开发」提成唯一 P0 并引入 Pipeline 编排基座，这个项目断断续续做了两个月。之前我写过一篇《从 Bug 修复到需求开发：iOS AutoFix Agent 的 V3-V5 演进之路》，把版本演进的脉络讲清楚了。

接下来我的重心会转到和其他同学共建另一个 Agent 项目上。所以趁记忆还热乎，给 iOS AutoFix 做一份阶段性收尾——这篇不再复述版本演进，而是把这一年踩过坑、验证过的与领域无关、可以直接搬到下一个 Agent 项目的工程经验沉淀下来。

从 Bug 修复到需求开发：iOS AutoFix Agent 的 V3-V5 演进之路

在上一篇文章里，我解释了为什么选择自建 Agent 架构，而不是做 IDE 插件——核心在于要拥有”流程控制权”，而不是”平台适配权”。

那篇文章写完后，系统先后经历了 V3、V4、V5 三个大版本的迭代。我打算在这篇里把这段演进过程讲清楚：每一版做了什么、为什么这么做、踩了什么坑、优化思路是什么。

问题现象

在 Android Studio 中 Build / Sync 报错：

1
2
3
4
5
6
7
8

Could not compile initialization script '.../ijMapper1.gradle'.
> startup failed:
  General error during conversion: Unsupported class file major version 65

java.lang.IllegalArgumentException: Unsupported class file major version 65
    at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:199)
    ...
    at com.intellij.gradle.toolingExtension.impl.modelAction.GradleModelFetchAction...

从命令行直接执行 ./gradlew tasks 完全正常，只有通过 Android Studio 触发构建时才报错。

为什么要做一个 iOS Bug 自动修复的 Agent 程序

一、为什么不直接做 IDE 插件

如果目标只是”在 IDE 里更方便地写代码”，那直接基于 CodeBuddy 这类 Agent IDE 做插件，通常更快、更省成本。

但我的目标不止于此：

• 把”修复/分析/定位/验证”沉淀成可复用能力
• 让 Agent 不依赖某个 IDE 才能工作
• 把人的经验流程产品化、平台化、自动化
• 围绕 iOS 问题定位、日志分析、修复建议形成领域能力

这些目标决定了我需要一套自建的 Agent 架构，而不是一个 IDE 插件。

原文地址

近期，由小红书联合多伦多大学等高校的研究人员发布了 《SWE-Bench Mobile》（2602.09540） 论文，内容主要是评估 LLM 智能体在处理真实生产级移动端应用开发任务时的能力，并提出了首个针对该领域的基准测试——SWE-Bench Mobile。

这个论文对比之前那些简单的需求场景，明显更具备说服力，最重要的是，用真实的数据给目前的 AI 狂热浇一浇冷水。