task: 支持 MindIE Agent 对接（知识、执行与评测交接） #374

Activity

1. jiangkuaixue123

   added

   kind:taskBounded delivery task with a delegated sliceBounded delivery task with a delegated slice

   area:knowledgeKnowledge line: packs, skill library, knowledge admissionKnowledge line: packs, skill library, knowledge admission

   status:proposedWaiting for the decision named in the status blockWaiting for the decision named in the status block

   area:workbench

   on Nov 9, 2026
2. amy-why-3459 commented on Nov 9, 2026

   

   amy-why-3459

   on Nov 9, 2026 – with Cursor

   Collaborator

   More actions

   感谢整理，这个跟踪入口把 #316 第 5 项的边界写得很清楚。看完有几点建议，供首期范围确认时参考：

   1. 先定方向，再定接口。 建议首期只选一个方向，例如“MindIE Agent 作为宿主侧调用 InferRSI 公开能力（知识交付 + 独立评测）”，反向调用留到第二期。这样优化循环和权威状态天然归 MindIE 宿主一侧，InferRSI 只提供无状态的准备 / 记录 / 评测入口，可以直接避开嵌套循环和双重重试的问题。如果倾向反方向，也建议在 issue 里明确写一句“循环与预算由谁持有”，作为后续 PR review 的判据。

   2. 接口形态建议优先 CLI。 CLI 的输入输出最容易做成契约测试的固定样例，也不需要在宿主进程里引入 InferRSI 的 Python 依赖；MCP 可以作为 CLI 之上的薄包装后补。不过这取决于 MindIE 宿主目前对 MCP / 本地命令的支持情况，这一点需要 @jiangkuaixue123 确认。

   3. 交接契约建议先给一份最小样例。 第 2 节的表格已经很完整，建议首期验收第一项直接附一份成功路径的输入 / 输出 JSON 样例（含 PreparedRef / RecordRef / AssessmentRef 映射），再配身份错配、产物缺失、超时取消三个失败样例。其他场景可以在样例稳定后再补，避免一开始契约面过大。

   4. 版本固定。 调研基线是 Dong1017/mindie-agent@6a57cc8（channel 0.1.12），建议实施 PR 里把实际验证的宿主 / 插件 / 知识版本写进支持矩阵，CI 中的契约测试也对这组版本固定，避免上游 channel 更新后悄悄失配。

   5. Admission 与远端执行分开验收。 同意文中“知识调用通过 Admission 不等于远端命令受租约保护”的判断。建议在验收标准里单独列一条：取消请求发出后，记录实际退出状态；未确认停止时结果标为不确定，而不是成功或失败。

   有一个问题想确认：首期的真实工程任务，是打算在 CPU fixture 上先跑通交接链路，还是直接选 NPU 任务？这会影响验收人和环境审批的安排，建议在范围确认时一并写明。
3. Dong1017

   added

   area:harnessHarness module: profile, A/B loop, quality gates, evidence reportsHarness module: profile, A/B loop, quality gates, evidence reports

   and removed

   area:workbench

   on Nov 9, 2026
4. jiaran-king commented on Nov 10, 2026

   

   jiaran-king

   on Nov 10, 2026

   More actions

   👀
5. jiaran-king commented on Nov 10, 2026

   

   jiaran-king

   on Nov 10, 2026

   Last edited by jiaran-king

   More actions

   以下是我设计的初版方案。

   一、架构图：MindIE 接在哪里？

   建议首期采用同一个 Codex Agent、同一个会话的方案。InferRSI 组织优化任务、管理预算、记录执行并独立评测；Codex Agent 修改代码；MindIE 在候选生成阶段向这个 Agent 提供昇腾知识。下面是待评审的实现方案。

   同一个 Codex 会话
   │
   ├─ 1. Agent 使用 InferRSI，取得本轮任务、基线和验收条件
   │
   ├─ 2. 用户在当前会话显式启用 MindIE 知识
   │     Agent 查询相关经验，读取选中的条目，取得正文、来源和版本
   │
   ├─ 3. Agent 修改目标仓库，交付候选 v1
   │
   └─ 4. Agent 将候选交给 InferRSI
         ├─ 关联本轮任务、实际读取的知识和 v1 的确切版本
         ├─ Harness 管理受控执行、预算和运行记录
         └─ Benchmark 按预先约定的规则检查正确性和性能
   

   这样设计的原因是，InferRSI 现有 Codex 插件已经把调查和代码修改交给宿主 Agent；MindIE 的知识启用又以会话为单位。两者可以在同一次候选生成中配合。首期建议将 MindIE 的接入范围限定为知识检索和读取，设备执行沿用所选任务的受控路径。InferRSI 宿主说明 · MindIE 会话规则 · InferRSI 架构决定

   二、预计改哪些地方？

   1. InferRSI 的 Codex 宿主入口：让 Agent 和使用者知道怎么走一轮

   • 修改 plugins/inferrsi/skills/inferrsi/SKILL.md。 在现有调查与诊断流程中说明：当前会话启用 MindIE 后，Agent 如何读取适用条目、保留来源和版本，并把这次读取关联到随后交付的候选。
   • 修改 docs/codex-plugin.md。 增加一个面向使用者的 RMSNorm 示例，说明如何在同一会话启用知识、完成代码修改，以及到哪里查看运行结果。宿主 Skill · 插件使用指南

   2. InferRSI 的宿主 / Apps 适配层：记录实际交付给 Agent 的知识

   • 复用现有记录格式。 将获准留存的正文映射到 context.text，将知识来源、固定版本和条目位置映射到 context.sources[] 中的 ref、revision、locator，通过已有的 campaign assemble-trace 组装记录。
   • 按实际读取范围记录。 例如搜索命中五条、Agent 只打开第二条，记录中应能看出实际交付的是第二条的哪些内容。
   • 先验证字段，再决定代码量。 InferRSI 的 optimization trace 保存调用方确认过的上下文；仅凭事后填写的引用，无法证实这次读取确实发生过。建议先取一份真实 MindIE 返回样例，检查能否与当前会话及生成轮次关联。若需要格式转换，再把转换代码放在宿主或 Apps 边界，并与 task: Apps 应用层详细设计与迁移计划（CLI / Python / Plugin） #371 的接口设计对齐。现有记录格式 · Apps 设计提案 #371

   3. InferRSI 的候选与评测路径：确保评测跑的是 Agent 交付的那一版

   • 复用 record_candidate(...)。 src/inferrsi/harness/campaign_records.py 已能将轮次、candidate_id、run_id 和 optimization_trace_ref 关联到候选记录。
   • 补充契约测试。 在 tests/test_optimization_trace.py 增加 MindIE 来源样例，验证读取内容和版本能完整保留。宿主侧覆盖知识未启用、读取结果缺失或轮次错配时的处理。
   • 复用 task: connect engineering tasks to existing Agent execution and evaluation #337 的候选交接与独立评测工作。 端到端重点验证一种实际情况：Agent 交付 v1 后，工作区又改成 v2，先前那次评测仍能指回实际运行的 v1。正式验证前需确认 task: connect engineering tasks to existing Agent execution and evaluation #337 可用的接口和版本。候选记录实现 · 现有测试 · 真实 Agent 接入 #337

   4. MindIE Agent 一侧：先判断现有接口是否够用

   在选定的宿主和插件版本上，执行一次真实的 query（搜索）和 explain（按引用读取）。用 explain 的实际返回核对正文、来源、知识版本和条目位置。字段齐全即可复用现有插件；若确实缺少稳定引用，再把具体缺口提交给对应的 MindIE 组件。MindIE 使用示例

   三、Workflow：拿 RMSNorm 优化走一轮

   RMSNorm（均方根归一化）是模型中对一组数值做归一化的算子。选它作为候选验收任务，是因为 #337 已将它列为内置 NPU 任务，有明确的输入、参考输出和性能测量目标。这里建议验证的是：Agent 能否借助 MindIE 的昇腾知识修改算子，再由 InferRSI 检查这份实际修改。 #337 任务范围

   1. 定任务。 在 InferRSI 中固定原版 RMSNorm、测试输入、精度容差、计时方法、允许修改的文件和本轮预算。
   2. 读知识。 用户在当前 Codex 会话启用 MindIE。Agent 查询归约计算或中间精度相关经验，读取适用条目，保留本轮实际取得的内容与引用。
   3. 交付 v1。 同一个 Agent 修改算子代码。InferRSI 将本次生成、知识引用和 v1 的确切代码版本关联起来。
   4. 独立评测 v1。 在获准的设备环境中运行经审核的候选。用相同输入比较参考输出，再按约定的方法测量基线与 v1 的耗时。精度超限就记录失败；测量证据不足就保留 INCONCLUSIVE。
   5. 结束或继续。 InferRSI 按任务规则和剩余预算决定是否继续。若 Agent 生成 v2，另记一次生成和评测，保留 v1 的结果。

   建议验收标准：从一次真实运行的结果，验收人可以反查本轮读了哪些 MindIE 知识、Agent 交付了哪版代码、评测实际运行了哪版，以及得出了什么结论。CPU 样例可先验证交接接口；若最终选择 RMSNorm 的 NPU 优化，设备端验收需确认可用题包、真实设备、候选审核方式和验收人。结果完整可信时，即使没有测得加速，也可以验收对接流程。

   请 reviewer 确认

   是否认可分工：InferRSI 管理优化循环，同一个 Codex Agent 通过 MindIE 读取知识并生成候选？
6. jiangkuaixue123

   self-assigned this

   on Nov 10, 2026