25. Harness Engineering Improvements (Agent 上下文与生命周期优化)

1. 背景与目标 (Background & Objectives)

随着 LemonBoss 架构从单体 Agent 演进为多租户下的“数字代理公司（Corporate OS）”，我们的宏观阵法（层级汇报、跨部门协作、OKR 分解）已初具规模（参考之前的相关系统设计）。然而，基于对前沿 Harness Engineering 最佳实践的深度反思，单个 Agent 节点在处理长链路复杂任务时，依然面临“上下文衰减（Context Decay）”、“信息污染（Noise Pollution）”、以及“试错成本高昂（High Trial Cost）”三大核心痛点。

为了确保底层每一个“数字员工”即使在超长命名的商业运营中也不会发生注意力弥散（Attention Decay），我们提出以下补充重构计划。该计划的核心思想是：做精信息喂食、隔离决策上下文、构建自查闭环。

---

2. 核心改进计划 (Core Improvement Plans)

改进点一：将四阶段分解固化为基座 Agent 的四大元技能 (Meta-Skills Integration)

现状痛点：当前单个 session 会承载一个 Agent 从“思考规划”到“调用执行”直至“修复 Bug”的全生命周期。后期 Session Prompt 过长（超过甜区限度），导致关键指令被稀释，且执行边界模糊。 改进策略：我们将 Research -> Plan -> Execute -> Verify 不仅作为宏观规范，而是实际固化为基座 Agent (Base Agent) 标准配备的四大元技能包（Meta-Skills）。

1. 按需装载独立技能树 (Dynamic Skill Invocation)：在底层设定中，为每一个 Base Agent 提供四个相互独立的元技能引擎接口。每次面临新任务，代理根据自身所处的流转阶段，主动调用加载专属的技能包（如只调用 skill_plan 去出方案）。
2. 基于技能切换的 Context Flush（上下文切断与防污染）：一旦当前阶段的技能执行完毕（例如调用 Planner 技能产出了 architecture.md），该 Session 生命周期强制结束归档。当进入下一环节调起 skill_execute 技能时，新开一条绝对干净的 Session，只传入上一步确定的干货文件，彻底断绝跨阶段的幻觉与信息污染。

改进点二：实施“事前阻断阀”管理 (Human/Master pre-approval)

现状痛点：人类往往在 Agent 完全做错产出一堆无效代码后（即事后）去执行 Code Review，纠错成本极高。 改进策略：

1. 杠杆前置审查：当 CEO 或 CTO 这类管理层 Agent 产出“规划文档（Plan / Architecture）”后，系统强制挂起该节点的 status。
2. 等待放行命令：必须由 Master（人类用户） 或高阶 Validator/Innovator Review 批准该规划文档。一旦驳回，重做 Plan；一旦批准，才能生成下游子任务清单（Task Spawning）并消耗算力。以一行 Plan 的纠正，避免百行代码的错误生成。

改进点三：渐进式披露与去工具化 (Progressive Disclosure & Minimized Tools)

现状痛点：为了提供强大的功能，在 tools.md 或 System Prompt 里塞入海量工具说明与技能细则，导致模型注意力过载或陷入决策瘫痪（Decision Paralysis）。 改进策略：

1. 多级目录动态按需加载：确立三级机制：
   • Level 1 (CLAUDE.md / identity.md)：只讲最最核心的存活元规则和找资料入口。
   • Level 2 (SKILL.md)：作为外挂组件引擎，只有触发特定领域关键词，引擎才将其注给 Agent system_prompt。一旦切走任务则将其卸载（Unload）。
   • Level 3 (references)：基于 RAG 工具被动按需调取日志或全量文件。
2. 修剪泛洪工具群：将非必须的复杂组合 API 下架。退守“最强的万能扳手”：赋予 Agent 沙盒受控的终端执行与代码编写权（如受限的 Python 解释器或 bash），让 Agent 现写代码去满足需求，而非提供写死上百个微工具集。

改进点四：单体自治理的“微小自反思闭环” (Micro Self-Verification)

现状痛点：完全依赖事后外置的角色（如 QA-Judge 或者遭遇硬报错再触发反馈），链路长且对中控要求高。 改进策略：

1. 植入 Local Verify Hook：规定在下级执行类 Agent 调用 report_task 汇报 status: PASS 之前，必须调用自身的沙箱测试或执行一次自我反思的 verify 工具。
2. Autoresearch Error Loop：为底层 Agent 本地增加 _lessons.md（试错经验暂存区）。在执行重试（Retry）循环时，如果不通过，先强制写一条经验记录到 _lessons.md 中。下次 retry 带上本条经验执行，避免单次死循环卡点。此级循环不惊动顶层的 Innovator（FDE），实现“兵不烦将”。

改进点五：引入算力经济学观测 (Cost & Profiling Observability)

现状痛点：对“系统表现和行为”透明（有 Logs），但对“运营成本”无感知，不符合 Corporate OS（企业组织）要求。 改进策略：

1. 建立 logs/billing 观测维度：在 pipeline_runs 和 audit 同级，加入 Token 消耗监测系统。
2. 精确计算每一次交接任务“花费的 API 计价预估”。给 CEO 提供财务数据维度支持，帮助甄别“能力较弱导致长耗时高频失败”的节点，为其发起汰换重构提供商业依据。

---

3. 落地 Roadmap (Implementation Roadmap)

阶段	里程碑 (Milestones)	涉及模块 (Modules)	预期时间
Phase 1	微观验证引入：在现有节点中强制引入自我校验 (Local Verify)，以及局部 _lessons.md。	agent-chat.js, 基础 templates/ 补充设定	P1 优先
Phase 2	四大元技能装配与重构：为 Base Agent 植装并切分 Research/Plan/Execute/Verify 四大独立技能入口，支持阶段流转中的 Context Flush。	memory-service.js, boss-meta-capabilities, master-session	P1 优先
Phase 3	事前阻断流程化：集成规划节点停摆拦截，接入前端 UI 以获得 Human/Master 的手动 Approved 后才能唤醒下游。	schema/goals, Web UI 组件	P2 规划
Phase 4	重置工具与按需挂载：清理多余的工具并实施 SKILL.md 动态路由加载机制，提高上下文利用率甜区表现。	skill-registry/service, 工具池整理	P2 规划
Phase 5	经济学审计引入：Token 数理追踪统计埋点，提供可视化报表支持（Cost Tracker Dashboard）。	logger/billing_service	P3 未来探讨

最后修订记录:

• 本规划文档由对行业 Harness Engineering 原理和 LemonBoss 特性对比后的工程反思形成，将指导未来一至两个大版本的演进。