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-1Harness 不是框架是执行骨架2.1 Harness 和 Agent 的区别很多人第一步就搞混了我见过不少团队在选型时把 Harness 当成 Agent 框架来用结果越用越别扭。这里必须先把概念掰清楚。Agent是“决策者”它负责理解目标、拆解任务、选择工具、决定下一步做什么。Harness是“执行容器”它负责给 Agent 提供一个稳定的运行环境包括工具调用、状态管理、错误捕获、轨迹记录。用生活化的类比Agent 是司机Harness 是车。司机决定去哪、怎么走车负责把动力传下去、把颠簸过滤掉、把仪表数据记下来。NeoHorse-1 里的 Harness 设计有几个关键点值得注意工具调用标准化不管你是接搜索、接代码执行、接数据库Harness 层统一封装成可追踪的 action每次调用都有输入、输出、耗时、状态。状态快照与回滚Agent 每走一步Harness 会存一个状态快照。如果 RSI 判定这一步走歪了可以直接回滚到上一个干净状态而不是从头再来。执行轨迹结构化不是简单记日志而是把轨迹组织成“目标-动作-观察-评估”的四元组方便后续 RSI 消费。提示如果你现在的 Agent 项目还在用print打日志来调试那基本可以判断你的 Harness 层是缺失的。日志是给人看的轨迹是给系统自己看的两者目的不同。2.2 为什么 Harness 层决定了 Agent 能不能上生产我踩过的一个坑早期做 Agent 项目时工具调用直接写在 Agent 的提示词逻辑里模型说调什么就调什么。结果有一次模型连续调了同一个搜索接口七次每次都返回相似结果Agent 陷入死循环烧了一堆 token 才被人工发现。后来加了 Harness 层情况完全变了。Harness 可以在工具调用前做前置校验比如同一个工具连续调用超过三次就拦截调用后做后置校验比如返回结果为空就标记为异常异常积累到阈值就触发 RSI 介入。这套机制让 Agent 的稳定性从“看运气”变成了“有兜底”。NeoHorse-1 在 Harness 工程上的一个亮点是分层拦截层级拦截内容触发动作L1 调用前参数合法性、频率限制拒绝调用并返回错误码L2 调用中超时、资源占用中断并记录异常轨迹L3 调用后结果质量、目标偏离度标记异常并通知 RSIL4 轮次后整体进度、成本消耗决定继续、回滚或终止这张表是我根据常见 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_retries3): 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%。这个开销值不值得取决于你的场景。如果是实时对话类 Agent50% 的开销可能不可接受。如果是后台批处理任务那稳定性比速度重要得多。优化思路有几个快照按需保存不是每一步都存全量快照只存关键状态的变化量校验异步化后置校验可以异步做不阻塞主流程轨迹分级记录正常轨迹只记摘要异常轨迹才记全量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 开发不妨把它的设计思路拿来对照自己的项目看看哪些坑可以提前避开。