长期项目里的 Agent Harness，可能需要元认知自演化能力 我感觉个人 Agent Harness 最缺的不是执行，而是自我迭代能力， 很多 Harness以及Agent框架，本质上还是偏执行环境，这个模式当然有用，但如果放到长期项目里，比如做代码项目、做产品原型、写论文，就会出现困难，所以一个更适合长期项目的 Harness，不应该只是执行器，而应该具备一种元认知自演化能力。 Meta-Cognitive Self-Evolving Agent Harness for Long-Term Project Execution 意义：让 AI 在既定项目目标下，具备自我诊断、自我建设、自我评价更新和阶段性目标规划能力。即一种在人工设定总目标和安全边界下，能够主动识别项目缺口、提出阶段性目标、发现自身能力不足、建设新能力、更新审查机制、治理记忆与技能库，并通过验证、审批和回滚机制实现可控持续进化的项目型智能体框架。 一、为什么需要元认识自演化，解决了什么问题？ 普通 Harness 的问题是： 执行路径：人设定目标——人设定流程——Agent 执行——人审查——人指出问题——人再下令修改 存在的问题缺口： 每次都依赖人重新提醒； 反馈不能自动沉淀； 审查机制固定，容易停滞； 项目缺口需要人主动发现； 能力库越积越乱； Agent 不知道自己哪里有缺漏； 系统无法证明自己真的变系统、智能。 因此我们需要在以下方面进行整改： 人设定总目标和边界 Agent 跟踪项目状态——识别项目缺口——提出阶段目标——执行任务——审查结果——审查自己的审查机制——发现自身短板——建设新能力——治理记忆——技能和规则库——用回归测试验证是否变强——人审批高风险变更——系统版本化和可回滚 这样agent就变成从执行工具环境框架升级成可自演进的项目协作者。 参考： 1 Reflexion Reflexion 让语言 Agent 在任务完成后根据反馈进行语言反思，并把反思文本存入 episodic memory，用于后续任务决策。通过语言反馈 + 记忆实现持续改进。 arXiv.org Reflexion: Language Agents with Verbal Reinforcement Learning Large language models (LLMs) have been increasingly used to interact with external environments (e.g., games, compilers, APIs) as goal-driven agents. However, it remains challenging for these language agents to quickly and efficiently learn from... 2 Meta-Rewarding / LLM-as-a-Meta-Judge 提出 Meta-Rewarding，让模型不仅评价自己的回答，还进一步评价“自己的评价”。也就是 judge evaluates responses，meta-judge evaluates judgments。 arXiv.org Meta-Rewarding Language Models: Self-Improving Alignment with... Large Language Models (LLMs) are rapidly surpassing human knowledge in many domains. While improving these models traditionally relies on costly human data, recent self-rewarding mechanisms (Yuan et al., 2024) have shown that LLMs can improve by... 3 ADAS 自动创造更强的 Agentic System，包括发明新的构件，或以新的方式组合构件。提出 Meta Agent Search，让 meta agent 迭代编写新的 agent 代码并基于评估结果继续搜索。 arXiv.org Automated Design of Agentic Systems Researchers are investing substantial effort in developing powerful general-purpose agents, wherein Foundation Models are used as modules within agentic systems (e.g. Chain-of-Thought, Self-Reflection, Toolformer). However, the history of machine... 二、结构 具体架构: 从架构来说分四层：项目目标层，任务执行层，评价与元评价层，自我建设与治理层 第一层：项目目标层 意义：这个项目到底要完成什么？现在做到哪一步？还缺什么？ 功能判断： 1当前项目总目标是什么？ 2当前已经完成了什么？哪些部分还缺失？ 3哪些缺口会影响最终交付？下一阶段应该补什么？ 4新目标是否偏离原始方向？ 模块具备：项目状态跟踪器，项目缺口分析器，阶段目标生成器，目标一致性检查器，阶段计划生成器 第二层：任务执行层 相当于传统 Harness 的主体，负责把目标变成可执行动作。 第三层：评价与元评价层 意义：审查输出，还要审查审查机制本身。 功能判断： 1结果有没有问题 2为什么原来的审查器没有发现这个问题？当前检查清单是不是太浅？ 3评价标准是不是过时？ 4测试样例是不是不够？ 5评分规则是不是鼓励了错误行为？ 对应模块：结果审查器、元审查器、评价规则管理器、测试样例库、风险评估器 第四层：自我建设与治理层 意义：自我演进，系统化，可续化 功能判断： 1我擅长什么？我哪里经常失败？ 2失败是因为知识不足、工具不足、流程不足、评价不足，还是目标不清？ 3我需要新增什么工具、规则、技能或模块？ 4已有记忆是不是混乱？已有规则有没有冲突？ 5哪些经验应该压缩？哪些技能应该合并？哪些模块应该重构？ 模块：自我能力模型，能力缺口识别器，失败归因器，能力建设器，记忆治理器，技能库管理器，架构演化器，版本管理与回滚器 效果：把可演化对象扩展到模型、记忆、工具、架构等多个组件 三、闭环 任务执行闭环，能力自建闭环，评价机制自更新闭环，目标演化闭环，记忆与技能治理闭环 1.任务执行闭环 目标 → 规划 → 执行 → 输出 → 审查 → 修正 即基础的harness效果 2．能力自建闭环 执行失败 → 失败归因 → 能力缺口识别 → 生成补强方案 → 新增规则、工具、流程或技能 → 验证是否改进 3.评价机制自更新闭环 外部反馈指出问题 → 原审查器没有发现 → Meta-Critic 分析审查遗漏原因 → 更新检查清单、测试样例、风险规则 → 用旧任务回归验证 4.目标演化闭环 项目状态跟踪 → 项目缺口分析 → 提出阶段性目标 → 目标一致性检查 → 人类审批关键目标 → 生成阶段计划 5.记忆与技能治理闭环 经验积累 → 重复检测 → 冲突检测 → 压缩归纳 → 技能封装 → 版本化保存 → 低频归档或删除 四、整体流程 Step 1：人类输入总目标和安全边界 例如：完成一篇面向 EPSR 的 VPP 调度论文。 Step 2：系统建立项目状态模型 记录已有材料、当前进度、关键约束、评价标准。 Step 3：系统分析项目缺口 判断还缺哪些实验、文档、验证、图表或审稿准备。 Step 4：系统提出阶段性目标 例如：补充可行性验证、补充鲁棒性分析、完善相关工作。 Step 5：目标一致性检查 确认新增目标是否服务于总目标，是否引入目标漂移。 Step 6：任务执行 调用工具、技能、流程完成具体任务。 Step 7：结果审查 检查质量、风险、格式、逻辑、事实一致性。 Step 8：元审查 检查审查器是否遗漏问题，是否需要更新评价机制。 Step 9：能力缺口识别 判断失败来自知识、工具、流程、记忆、评价还是目标规划。 Step 10：能力建设 新增规则、技能、工具、流程、测试样例或模块。 Step 11：记忆和技能治理 压缩重复经验，合并规则，归档低频内容，解决冲突。 Step 12：回归验证 用固定任务集测试更新是否真的提升。 Step 13：版本化与人工审批 低风险更新自动保存，高风险更新等待人类确认，错误更新可回滚。 这几天操作有点感悟，借助ai讨论，仅供参考，感觉个体构建harness需要具备这样的迭代能力，随便水个贴 1 个帖子 - 1 位参与者 阅读完整话题