1. 这匹“黑马”到底踩中了什么痛点
AI 圈每隔几个月就会冒出一个新名字，但大多数热闹三天就散了。NeoHorse-1 这次能被讨论，我认为核心不在于它跑分多高，而在于它把RSI、Harness、Agent这三个原本各说各话的概念拧成了一股绳。先说结论：它想解决的是“Agent 能干活但干不长、干不稳”的老毛病。
过去一年，大家做 Agent 项目的普遍路径是：选一个框架，接几个工具，写一段提示词，然后祈祷它别在第三步就崩。问题出在哪？出在 Agent 的“执行层”和“评估层”是脱节的。模型输出一段计划，工具执行完，结果好不好全靠人肉看。NeoHorse-1 的思路是把Harness（执行骨架）和RSI（递归自我改进）绑在一起，让 Agent 每跑完一轮就自动评估、自动修正，而不是等人来救场。
这听起来像学术概念，但落到工程上其实很实在。你可以把它理解成给 Agent 装了一个“随堂测验”机制：每完成一个子任务，Harness 负责记录执行轨迹，RSI 负责判断这条轨迹是否偏离目标，如果偏了就回滚重来。这套东西的价值在于，它让 Agent 从“一次性执行”变成了“可迭代执行”。
适合谁来关注这个方向？如果你正在做 Agent 开发、正在选型 Agent 框架、或者被“Agent 跑一半就报错”折磨过，那这篇内容值得往下看。我会把 NeoHorse-1 涉及的核心机制拆开，结合 Harness 和 Agent 的常见工程实践，讲清楚它为什么可能成为一匹黑马，以及你在自己的项目里能抄哪些作业。
2. 拆开 NeoHorse-1：Harness 不是框架，是执行骨架
2.1 Harness 和 Agent 的区别，很多人第一步就搞混了
我见过不少团队在选型时把 Harness 当成 Agent 框架来用，结果越用越别扭。这里必须先把概念掰清楚。
Agent是“决策者”，它负责理解目标、拆解任务、选择工具、决定下一步做什么。Harness是“执行容器”，它负责给 Agent 提供一个稳定的运行环境，包括工具调用、状态管理、错误捕获、轨迹记录。用生活化的类比：Agent 是司机，Harness 是车。司机决定去哪、怎么走，车负责把动力传下去、把颠簸过滤掉、把仪表数据记下来。
NeoHorse-1 里的 Harness 设计有几个关键点值得注意：
- 工具调用标准化：不管你是接搜索、接代码执行、接数据库，Harness 层统一封装成可追踪的 action，每次调用都有输入、输出、耗时、状态。
- 状态快照与回滚：Agent 每走一步，Harness 会存一个状态快照。如果 RSI 判定这一步走歪了，可以直接回滚到上一个干净状态，而不是从头再来。
- 执行轨迹结构化：不是简单记日志，而是把轨迹组织成“目标-动作-观察-评估”的四元组，方便后续 RSI 消费。
提示：如果你现在的 Agent 项目还在用
2.2 为什么 Harness 层决定了 Agent 能不能上生产
我踩过的一个坑：早期做 Agent 项目时，工具调用直接写在 Agent 的提示词逻辑里，模型说调什么就调什么。结果有一次模型连续调了同一个搜索接口七次，每次都返回相似结果，Agent 陷入死循环，烧了一堆 token 才被人工发现。
后来加了 Harness 层，情况完全变了。Harness 可以在工具调用前做前置校验（比如同一个工具连续调用超过三次就拦截），调用后做后置校验（比如返回结果为空就标记为异常），异常积累到阈值就触发 RSI 介入。这套机制让 Agent 的稳定性从“看运气”变成了“有兜底”。
NeoHorse-1 在 Harness 工程上的一个亮点是分层拦截：
| 层级 | 拦截内容 | 触发动作 |
|---|---|---|
| L1 调用前 | 参数合法性、频率限制 | 拒绝调用并返回错误码 |
| L2 调用中 | 超时、资源占用 | 中断并记录异常轨迹 |
| L3 调用后 | 结果质量、目标偏离度 | 标记异常并通知 RSI |
| L4 轮次后 | 整体进度、成本消耗 | 决定继续、回滚或终止 |
这张表是我根据常见 Harness 工程实践整理的，NeoHorse-1 的具体实现细节官方没有完全公开，但逻辑上跑不出这个范围。你在自己项目里也可以按这个分层思路来设计，不一定非要等 NeoHorse-1 开源。
2.3 RSI 在 Harness 里扮演什么角色
RSI 全称是 Recursive Self-Improvement，递归自我改进。这个词听起来很玄，但在 Agent 场景里它其实很具体：让 Agent 根据自己刚才的执行轨迹，调整下一步的策略。
举个实际例子。假设你的 Agent 要完成“查一家公司的专利信息并生成摘要”这个任务。第一轮它调了专利数据库接口，返回了一堆原始数据，但摘要生成得很差。没有 RSI 的情况下，这个差结果就直接交付了。有 RSI 的情况下，Harness 会把“摘要质量低”这个评估信号传回去，RSI 模块会分析：是提示词不够具体？是数据没清洗？还是模型选错了？然后针对性地调整下一轮的执行策略。
NeoHorse-1 把 RSI 和 Harness 耦合在一起的好处是，评估信号不需要人工标注。Harness 记录的执行轨迹本身就包含了大量可用的评估信号：工具调用成功率、结果非空率、目标关键词覆盖率、轮次成本等。RSI 直接消费这些信号，就能做出相对靠谱的自我修正决策。
注意：RSI 不是万能药。如果 Harness 层记录的数据质量差，RSI 的修正方向也会跑偏。所以先把 Harness 做扎实，再谈 RSI，顺序不能反。
3. Agent 开发学习路线里，NeoHorse-1 能插在哪一环
3.1 从“能跑”到“跑得稳”的分水岭
市面上大部分 Agent 开发学习路线是这样的：先学提示词工程，再学框架（比如 LangChain 或类似工具），然后接几个工具跑通 Demo，最后部署上线。这条路线的问题在于，它跳过了“稳定性工程”这一环。
NeoHorse-1 出现的位置，恰好就在“跑通 Demo”和“部署上线”之间。它不教你写提示词，也不教你选模型，它解决的是：当 Agent 面对真实世界的混乱输入时，怎么保证它不崩、不偏、不烧钱。
我整理了一个对比表，帮你判断自己当前处在哪个阶段：
| 阶段 | 特征 | 典型问题 | 需要补充的能力 |
|---|---|---|---|
| 阶段一：能跑 | Demo 能完成单轮任务 | 换个输入就失败 | 提示词鲁棒性 |
| 阶段二：能多轮 | 支持多步任务 | 中间步骤出错无法恢复 | Harness 层设计 |
| 阶段三：能自愈 | 出错后能自动修正 | 修正方向不可控 | RSI 机制 |
| 阶段四：能进化 | 跨任务积累经验 | 经验迁移效率低 | 轨迹复用与抽象 |
NeoHorse-1 主要覆盖阶段二和阶段三。如果你的项目还卡在阶段一，直接上 NeoHorse-1 可能会觉得“太重了”。但如果你已经在阶段二挣扎了一段时间，那它的设计思路会很有启发。
3.2 一个最小可用的 Harness 实现思路
不一定非要等 NeoHorse-1 的完整实现，你可以先在自己的项目里搭一个最小 Harness。我用 Python 写过一个简化版，核心逻辑大概长这样：
class SimpleHarness: def __init__(self, max_retries=3): self.trajectory = [] self.max_retries = max_retries self.state_snapshots = [] def execute_action(self, action, params): # L1: 前置校验 if not self._validate(action, params): return {"status": "rejected", "reason": "validation_failed"} # 保存状态快照 self.state_snapshots.append(self._snapshot()) # L2: 执行并捕获异常 try: result = action.run(params) except Exception as e: self._rollback() return {"status": "error", "reason": str(e)} # L3: 后置校验 if not self._check_quality(result): self._rollback() return {"status": "low_quality", "result": result} # 记录轨迹 self.trajectory.append({ "action": action.name, "params": params, "result": result, "status": "success" }) return {"status": "success", "result": result} def _validate(self, action, params): # 检查参数合法性、频率限制等 recent_calls = [t for t in self.trajectory[-5:] if t["action"] == action.name] return len(recent_calls) < 3 def _check_quality(self, result): # 检查结果是否为空、是否包含目标关键词等 return result is not None and len(str(result)) > 10 def _snapshot(self): return {"trajectory_len": len(self.trajectory)} def _rollback(self): if self.state_snapshots: snapshot = self.state_snapshots.pop() self.trajectory = self.trajectory[:snapshot["trajectory_len"]]这段代码很粗糙，但它体现了 Harness 的核心思想：校验、快照、回滚、记录。你可以在这个基础上加 RSI 逻辑，比如当low_quality连续出现两次时，自动调整 action 的参数或换一个 action。
3.3 Agent 框架选型时，Harness 能力应该怎么评估
如果你正在选 Agent 框架，我建议把 Harness 能力作为核心评估维度，而不是只看它支持多少工具。具体看这几个点：
- 轨迹是否结构化：框架输出的执行记录是纯文本日志，还是结构化的 JSON？后者才能被 RSI 消费。
- 是否支持状态回滚：Agent 走错一步后，能不能回到之前的状态？还是只能从头再来？
- 异常处理粒度：是全局 try-catch，还是每个 action 独立处理？粒度越细，稳定性越好。
- 评估信号是否内置：框架有没有内置一些基础的评估指标（成功率、耗时、成本），还是全靠自己埋点？
NeoHorse-1 在这几个维度上的设计思路是值得参考的，即使你最终不用它，也可以拿这套标准去评估其他框架。
4. 实测中容易踩的坑与排查链路
4.1 工具调用死循环：从现象到根因的完整排查
这是我遇到过的第一个大坑，也是 Harness 层最常处理的问题。现象是：Agent 在某个步骤反复调用同一个工具，每次返回结果都差不多，但它就是不停。
排查链路是这样的：
- 先看轨迹：把 Harness 记录的轨迹拉出来，看重复调用的 action 是什么、参数有没有变化。如果参数完全一样，说明 Agent 没有从上次结果中学到东西。
- 再看评估信号：检查 RSI 模块有没有收到“结果质量低”的信号。如果没收到，说明 Harness 的后置校验没生效。
- 然后看提示词：Agent 的提示词里有没有明确“如果结果不理想，应该换策略而不是重试”？很多提示词只说了“重试”，没说“换策略”。
- 最后看工具设计：工具返回的结果是否包含足够的信息让 Agent 判断“这条路走不通”？如果工具只返回“成功/失败”，Agent 很难做出正确决策。
修复方案通常是三管齐下：Harness 层加频率限制，RSI 层加质量评估，提示词层加策略切换指令。只改一处往往不够。
提示：死循环的根因很少是单一的。我见过一个案例，表面上是 Agent 死循环，实际上是工具返回的数据格式和提示词里描述的不一致，导致 Agent 一直以为调用失败。所以排查时一定要交叉验证。
4.2 RSI 修正方向跑偏：评估信号设计比算法更重要
RSI 听起来很智能，但如果评估信号设计得不好，它会把你带进沟里。我踩过的一个坑：早期用“结果长度”作为摘要质量的评估指标，结果 RSI 学会了把摘要越写越长，最后生成一堆废话。
后来改成多维度评估：
- 关键词覆盖率：摘要是否覆盖了原文的核心关键词
- 信息密度：摘要长度与信息量的比值
- 事实一致性：摘要中的事实是否与原文一致（这个需要额外的事实核查工具）
评估信号一改，RSI 的修正方向立刻正常了。这件事给我的教训是：RSI 的上限取决于评估信号的质量，而不是算法本身有多复杂。你在设计 RSI 时，先把评估信号想清楚，再考虑用什么算法去消费它。
4.3 Harness 层性能开销：别让稳定性拖垮速度
加了 Harness 层之后，Agent 的执行速度会变慢，这是必然的。快照、校验、记录都要花时间。我实测下来，一个原本 3 秒完成的单步任务，加了完整 Harness 后变成 4.5 秒左右，开销大概 50%。
这个开销值不值得？取决于你的场景。如果是实时对话类 Agent，50% 的开销可能不可接受。如果是后台批处理任务，那稳定性比速度重要得多。
优化思路有几个：
- 快照按需保存：不是每一步都存全量快照，只存关键状态的变化量
- 校验异步化：后置校验可以异步做，不阻塞主流程
- 轨迹分级记录：正常轨迹只记摘要，异常轨迹才记全量
NeoHorse-1 具体怎么处理这个开销，官方资料里没有细说，但这是任何 Harness 工程都必须面对的问题。你在自己项目里也要提前想好这个权衡。
5. 从 NeoHorse-1 延伸出的 Agent 工程化思考
5.1 Agent 项目的“可观测性”比“智能性”更稀缺
现在做 Agent 的人都在追求更聪明的模型、更复杂的推理链，但真正让项目落地的，往往是可观测性。你的 Agent 为什么失败？在哪一步失败？失败时的状态是什么？这些问题如果答不上来，再聪明的 Agent 也没法上生产。
NeoHorse-1 把 Harness 作为核心组件，本质上就是在补可观测性这一课。它记录的轨迹不是给人看的日志，而是给系统自己消费的结构化数据。这个设计思路值得所有 Agent 项目借鉴。
我现在的做法是：任何 Agent 项目，先搭 Harness，再写 Agent 逻辑。Harness 跑通了，Agent 逻辑怎么写都不会太离谱。反过来，先写 Agent 逻辑再补 Harness，往往要重构。
5.2 Agent 评估不能只看最终结果
传统软件测试看最终输出对不对，但 Agent 的评估要复杂得多。一个 Agent 可能最终输出了正确结果，但中间走了十条弯路，烧了十倍成本。这种“结果对但过程差”的情况，只看最终结果是发现不了的。
Harness 层的轨迹数据让过程评估成为可能。你可以定义这些过程指标：
- 路径效率：实际步数 / 最优步数
- 工具调用准确率：有效调用 / 总调用
- 回滚率：回滚次数 / 总步数
- 成本偏差：实际成本 / 预算成本
这些指标比最终结果更能反映 Agent 的健康度。NeoHorse-1 的 RSI 机制如果消费了这些指标，那它的自我修正就会更有针对性。
5.3 小团队做 Agent 项目的务实建议
如果你是小团队，资源有限，我建议不要一上来就追求完整的 NeoHorse-1 式架构。可以分三步走：
第一步，先做一个最简 Harness，只记录轨迹和做基础校验。这一步的投入很小，但收益很大，能帮你快速定位大部分问题。
第二步，在 Harness 基础上加简单的 RSI，比如“连续两次低质量就换策略”。不需要复杂的算法，规则引擎就够了。
第三步，等轨迹数据积累到一定量，再考虑用机器学习方法做更智能的 RSI。这时候你有了数据，也有了明确的优化目标，成功率会高很多。
我见过太多团队跳过第一步直接做第三步，结果数据没有、目标不清，最后做出来的东西没人用。Agent 工程化是个渐进过程，别想着一步到位。
6. 关于 NeoHorse-1 后续值得关注的方向
NeoHorse-1 目前公开的资料还不多，但从它涉及的关键词来看，有几个方向值得持续关注。一是Harness 的标准化，如果它能定义一套通用的轨迹格式和评估接口，那不同 Agent 框架之间的互操作性会大大提升。二是RSI 的跨任务迁移，让 Agent 在一个任务上积累的修正经验能复用到另一个任务上，这是从“自愈”到“进化”的关键一步。三是Harness 工程的开源生态，如果围绕它形成插件体系，那工具接入的成本会大幅降低。
我个人在实际操作中的体会是，Agent 项目的瓶颈往往不在模型能力，而在工程基础设施。模型每年都在变强，但 Harness 和 RSI 这些工程层的东西，需要时间沉淀。NeoHorse-1 能不能成为黑马，最终要看它在这几个工程问题上给出了多扎实的答案，而不是看它的演示有多炫。如果你正在做 Agent 开发，不妨把它的设计思路拿来对照自己的项目，看看哪些坑可以提前避开。
