在 MindSpore AKG Agent 中的 Harness 设计：面向长程任务的状态机方法

当 Agent 需要连续运行数十小时甚至上百小时，且无人实时监督时，仅靠提示词约束其流程、记忆与行为边界，几乎必然会在若干轮后偏离预期。这些约束写入系统消息，指令偏移的风险始终存在。

更可靠的做法是：将约束以代码逻辑的形式实现在外层 harness 中，让 Agent 专注于推理、方向判断与代码修改，而流程控制与边界检查由 harness 保障。Anthropic 曾精辟地概括过纯提示词驱动的困境：

“这两种都不是良好的提示词范式：

一种是用脆弱的硬编码 if-else 过分详细地描述流程；

另一种是提示词过于模糊或错误地预设了上下文。”

何时赋予自由、何时划定边界？本文以 MindSpore AKG Agent 中的算子性能调优任务 Auto Research（自动研究循环）为场景，提出一种基于状态机的 harness 设计——在保留 Agent 自主性的前提下，让长程任务跑得稳、可追溯、可复现。

01 Auto Research 与 Agent Loop 结构

Auto Research 源名于 Karpathy 近期公开的一个原型项目，用于迭代优化其 nanochat（GPT-2 的简化教学实现）的模型与性能。任务设定为：人提供优化指标（如 validation loss）、待优化对象集合、版本控制工具（如 git）；其余循环由 Agent 执行。人定义目标和对象，Agent 尝试不同修改路径。该模式可推广至算子库性能调优、推理内核优化、数据配方搜索、提示词工程等场景。

Auto Research 的核心难点在于保持循环流程的长期稳定：每轮 Agent 需基于当前代码与反馈自主决策下一步，同时必须防止以下行为：

• 跳过评测环节
• 修改验收标准
• 遗忘已失败的方向
• 在上下文压缩后丢失历史经验

Agent 使用工具的常见模式是 ReAct（Reasoning-Action）交替循环。ReAct 在单步层面有效，但其线性结构无法自动完成“完成一轮后回到起点开始下一轮”的回环。Auto Research 恰恰需要这种回环。

围绕 ReAct 外层的约束设计，常见两类方案：

Auto Research 的目标通常没有预设的终止阈值，同时要求过程可复现、可审计。上述任一方案均不充分。需要一种在端到端自驱与固定 workflow 之间可连续调节的 harness 设计。

02 状态机与 ReAct 的分工

状态机位于固定流程与端到端自驱的中间地带。它不替代 Agent 做每步决策，仅规定：当前所处阶段、可转移的下一个阶段集合、需跨阶段保存的状态。

阶段内部仍运行 ReAct：Agent 自主决定查阅哪些文件、调用哪些工具、如何修改代码、何时判定本阶段完成。状态机定义流程框架，Agent在框架内执行ReAct。

以算子优化任务为例，用户提供：reference.py（PyTorch实现，用作写法参考和精度验证）和kernel.py（triton-ascend 算子的初始实现）。ReAct Agent 在外层状态机控制下执行四阶段循环：plan → edit → eval → decision，逐轮调优 kernel。其中包含两类状态机：

• Auto Research 主循环状态机：观察 → 修改 → 评测 → 回滚/保留。
• PLAN 状态机：每次代码编辑对应一个落盘的 PLAN 项，将探索动作与反馈从对话上下文中剥离保存。

连续失败时，框架自动挂起当前方向，启动一个上下文隔离的 Subagent 重新诊断并生成新方向。运行预算耗尽后输出总结报告。

在一个hybrid attention mask triton-ascend算子利用 Auto Research 迭代的过程中，外围框架实现了"保留性能最好的版本(KEEP)，回滚性能退化(DISCARD)、精度不符/编译错误(FAIL) 的版本”。图中曲线呈现的性能收益来自参数调整和写法改动，如：

1.算法重排：合并 seed kernel 中的若干次连续访存，移除冗余条件分支；

2.以 torch.ones + triu 取代 arange 广播 ；

3.去除冗余的 mask 构造。

可见 Auto Research 在triton-ascend算子调优过程中，能够自行组合、探索各种可叠加的性能优化写法。

在上述的 Auto Research 过程中，当 Agent 行为符合提示词描述时，状态机构成的约束几乎不被感知；约束实际发挥作用的时刻是 Agent 试图跳过计划、绕过评测、修改验收条件或提前结束时——harness 将流程拉回允许范围。

该结构可推广至更一般的工作流：

• 对于端到端验证类任务，其目标仅在于最终输出是否通过验收，中间过程无需追溯。此时状态机可退化为单状态：进入后执行 ReAct 循环，输出通过验收则终止，否则继续运行。
• 对于多阶段任务，则需为每个阶段明确定义交付物格式及阶段间的状态转移规则，Auto Research 即属此类。

同一任务在不同审计要求下，harness 的形态存在显著差异。若要求全流程可审计，状态机应划分更细粒度，交付物的格式约束亦须更严格；若仅关注最终结果的有效性，一个简单的循环结构配合少量提示词即可满足需求。

03 上下文管理：状态机带来的三个好处

状态机的另一个重要作用，是把上下文管理从 Agent 自己维护的内容里独立出来一部分。以下是三个和上下文管理相关设计。

3.1 落盘的 PLAN 文件

Auto Research 本质上是枚举式探索：将已有任务资料、性能观察、论文方法、社区经验和模型知识重组并逐一验证。每一尝试对应一个优化方向，每一次评测给出判断。有效探索的前提是：已失败的方向不再重复，未尝试的方向不被遗漏。这要求 Agent 长期保持对探索历史与结果的清晰认知。

仅依赖对话历史难以满足：

• 历史迅速膨胀超出上下文窗口；
• /compact 压缩后细节损失严重；
• 即使未溢出，Agent 决策需要的是简短结论，而非原始日志和完整代码变动；

PLAN 文件仅记录可复用、可比较的结论，如方向尝试、性能指标、失败原因摘要；原始评测输出、代码细节、重复的中间过程不进入 PLAN 文件，也不进入 Agent 上下文。这种记录方式比长度驱动的自动压缩更适配 Auto Research。

Agent 对长上下文的依赖因此降低：上下文被压缩或从断点恢复时，仅需读取 PLAN 文件即可恢复历史信息。一个昇腾算子优化任务可直接从 PLAN 文件与 git 历史等落盘产物中在新会话内重建，无需依赖底层 ReAct Agent 的上下文管理能力。

3.2 Subagent 的使用

Subagent 在此设计中作为上下文隔离工具，用于两类场景： 1、主 Agent 累积困境时切换视角：连续失败后，主 Agent 上下文被相似失败推理充斥，易陷入局部最优。启动一个零上下文的 Subagent 重新判断方向，比在原上下文内挣扎更有效。 2、处理与主线无关的复杂子任务：如跨文件代码定位、多步检索。Subagent 完成后再返回端到端结论，避免挤占主 Agent 上下文。

核心结论：多 Agent 拆解并不自动优于单 Agent。对于需要单一连贯输出的任务（如代码修改），多个 Agent 并行修改同一对象易导致风格冲突与重复失败。Auto Research 的主体执行始终由单一主 Agent 推进，仅在主 Agent 反复失败、需要新视角时才由 Subagent 临时介入。

3.3 端到端评测托管

Harness 设计应使 Agent 的 ReAct 动作集中于与任务直接相关的活动。以算子优化为例，Agent 最应进行两类操作：理解性能相关的资料、编写代码改动；这两者的产出直接服务于下一步判断。

除此之外，每轮运行还有大量必须执行但无需推理的动作：

• 运行评测、解析结果
• 判定改动优劣、保留或回滚版本
• 等待工具输出、检查必要条件

这些动作的触发条件和行为可预先确定，应由 harness 执行。若交由 Agent 执行，会产生两个问题：

• 这些动作的输出占用上下文，挤占真正有价值的性能信息
• Agent 有时会为了推进任务而修改这些步骤本身（如放宽验收容差、跳过检查或调整参照实现）

将上述步骤交由 harness 后：

• Agent 无法修改这些步骤，也无需为其分配上下文；
• Harness 负责回滚错误改动、保留最佳版本，Agent 每轮开始时均面对已验证的最佳代码状态；
• 每轮问题的结构保持一致，Agent 无需额外上下文处理历史遗留；
• Harness 输出格式相对固定，可提高 LLM 调用的 KV Cache 命中率，降低 API 开销；

04 总 结

本文讨论了在保留 Agent 自主性的前提下，通过 harness 层面约束使 Agent 工作流更加可控的方案。

Agent 的编排本身可视为一种新的编程范式：传统编程是设计确定性的、可预期产出的代码，使其主动执行；Agent 的自主性打开了确定性之外的空间，编程工作的重心相应地转移为约束 Agent 动作的可能空间。

文中基于状态机的 harness 设计，正是这一新范式下一种可调节且对 Agent 行为亲和的具体实现方式。

05 社区与互动

昇思MindSpore AKG是面向多硬件的图算协同加速器组件，致力于持续引领业界先进算子编译生成技术，助力开源人工智能生态繁荣发展。我们始终秉持开源开放的合作理念，持续欢迎开发者提交Issue、贡献代码或分享迁移经验。无论您是企业用户还是个人开发者，都可以通过直接访问官方代码仓参与共建或加入AKG SIG参与交流。

欢迎您通过AtomGit Issues来提交问题、报告与建议。

欢迎您通过社区论坛进行技术、问题交流。

欢迎您通过Sig来管理和改善工作流程，参与讨论。

让我们共同推动图算协同加速器的创新生态繁荣，让更多开发者受益于高效、易用的昇腾图算优化方案。