Meta-Harness：模型基座外壳的端到端优化
- [1. 基本概念](#1. 基本概念)
-
- [1.1. 方法对比](#1.1. 方法对比)
1. 基本概念
大语言模型（LLM）系统的性能不仅取决于模型自身的权重，还取决于其基座外壳（Harness）：即决定哪些信息需要存储、检索并呈现给模型的代码。
- 目前的外壳设计在很大程度上仍依赖手工；
- 现有的文本优化器与该场景的匹配度极差，因为它们对反馈信息的压缩过于激进：它们不具备历史记忆（Memoryless）、仅基于标量分数进行条件化推导，或者将反馈限制在简短的模板与摘要中。
1.1. 方法对比
Meta-Harness是一个专门针对 LLM 应用的外壳代码进行搜索的外环系统（Outer-loop System）。它使用一个智能体化提案器（Agentic Proposer），通过文件系统直接访问此前所有候选方案的源代码、评估得分以及执行痕迹（Execution Traces）。
- ACE 极其聪明地解决了智能体长任务中"记忆塌陷"的问题。它通过反思，把教训和攻略写进提示词文本（Context）里。但它最大的局限是只能动文字，动不了代码。无论它怎么写提示词，整个 AI 系统的 Python 流程框架（先干嘛后干嘛）是被人类工程师死死焊住的。
- ADAS 觉得 ACE 天天在提示词里修修补补太憋屈了，流程太死板。 于是它直接跨越到了图灵完备的代码空间。它让 AI 拥有了写 Python 代码的权限，去疯狂魔改和重新编排子智能体的工作流（Workflow）。
- Meta-Harness 认为ADAS把模型改第 15 版代码时，它看不到第 3 版、第 5 版、第 10 版代码长什么样，更看不到那些历史版本在运行几百个测试用例时，产生的成千上万行成功或失败的详细行为轨迹（Traces），信息在迭代中流失了。它打造了一个"外环系统"，彻底开放了文件系统的最高权限。它不给 AI 喂压缩过的摘要，而是把前几次尝试的全部源码以及运行过程中长达千万字的原始执行痕迹（Execution Traces/报错日志）原封不动地拍在桌上。AI 终于可以像人类黑客一样，用 grep 和 cat 盯着报错精准重构代码。
基座外壳（Harness）对比
- ACE外壳的状态： 绝对静态、焊死不变。 在做文本优化、精炼提示词攻略（Playbooks）时，它的外围一定有负责调用大模型 API、负责把用户输入拼装成 Prompt、以及负责把结果吐出来的 Python 代码。但是这个外壳代码是人类程序员手工写好并锁死的。大模型（ACE）只有在文本框里修改 playbook.txt 的权限。
- ADAS的外壳局部动态，只被允许去修改外壳里的"业务工作流（Workflow Code）"。 元智能体（Meta Agent）可以自己敲 Python 代码去发明新的子智能体。但它的活动范围依然被限制在"如何让模型思考、如何让多个模型辩论"的业务逻辑层。 而真正属于外壳工程底座的硬核部分（比如：底层的向量数据库怎么连接、长对话的 Token 怎么进行硬裁剪、内存怎么做多级缓存更新），依然是人类提前写好的、固定的背景板，ADAS 的代码搜索根本不会去碰、也碰不到这些底层大动脉。
- Meta-Harness 里人类工程师彻底把键盘让了出来，把整个系统最底层的最高文件系统权限（Filesystem）移交给了 AI。进化的对象包括负责 Store（存储）、Retrieve（检索）、Present（呈现与 Token 裁剪） 的基础工程底座。AI 提案器（Proposer）可以根据千万字的最原始运行日志（Traces），今天重构 RAG 的检索算法代码，明天重写内存的裁剪排版逻辑，后天魔改工具的动态调用接口。
ADAS 的困境： 因为它的日志里没有 Store、Retrieve、Present 的运行轨迹，所以它的 AI 程序员遇到报错时，只能误以为是大模型不够聪明，于是拼命去把业务代码改得更复杂（比如：让 3 个模型变成 5 个模型投票）。这导致系统越来越臃肿，不仅没解决底层工程问题，还让 Token 消耗量呈指数级暴涨。
Meta-Harness 的降维打击： 它的 AI 提案器通过 grep 一查日志，瞬间抓到了罪魁祸首："大模型挺聪明的没犯错，纯粹是 Present 模块没做 Token 裁剪把模型撑爆了！" 于是它直接去重构 Present.py 的代码。结果：只改了几行外壳代码，Token 消耗量直接暴降到 1/4，准确率反而暴涨。