本文将简略介绍初步设计等 OpenGIS Agent 的 harness 自进化框架，主要集中于其外围工具以及prompt等等自进化，并基于GIS benchmark 给出离线优化方案。
前言
在上一篇文章中，我们介绍了 Agent 自进化的三个方向，即 Artifacts Iterative Optimization、Agent Harness Self-improvement、Model Learning without Gold Answers，而对于 Agent 应用开发者来说，最热门的方向无疑是 Agent Harness Self-improvement，而对于我开发的空间分析 Agent 客户端 OpenGIS 来说，构建 Agent 自进化的基础设施可以带来两个方面的优化：
- 对于开发者（我本人）而言，可以通过开源的 GIS 行业 benchmark，让 OpenGIS Agent 自进化，提升系统的可用性，优化 tool、skill、operation（OpenGIS 特有的原子化 GIS 操作单元，类似于 ArcGIS 的工具）。不过这一步理论上来说不应该叫做自进化，而是离线优化，或者称之为 Benchmark-driven Harness Optimization，即便如此，我们还是希望使用自进化框架，辅以人工调优，来完成优化工作。
- 对于使用者而言，OpenGIS 如果支持自进化，那么可以使得 Agent 越用越好用，而这个落点我们希望集中于可复用的 skill 以及 operation，这样用户在多次交互中完成的一次复杂任务，通过 operation 沉淀后，可能通过一轮短对话就完成了。
同时，在上一篇文章中我们提到，Agent Harness Self-improvement 实际上包括了多个层级的工作，其中最深层次的是直接从 harness 架构层面的自进化，我个人认为对于一个倾向于稳定的、易于使用的客户端 Agent 来说，这一层次的改造太过于冒险，并且可以预见的在实际使用中容易出现不可用的行为。因此，OpenGIS 的自进化范围敲定在 harness 的外层，即 skill、operation等，以及隔离于系统提示词的自进化提示词 prompt_patch，具体的内容我们将在下文披露。
本文将介绍当前 OpenGIS 做了哪些架构方面的设计以支持自进化功能，并且尝试基于行业 benchmark，设计一个 Benchmark-driven Harness Optimization 流程，当然，自进化基建和离线优化流程将在开发过程中不断迭代，目前仍在技术选型与测试阶段，后续的优化以及结果会在以后的文章中披露。
OpenGIS 的自进化框架与基础设施
OpenGIS 已经有了一个较完整的 agent harness，LLM 通过 OpenGIS 提供的工程运行时使用地图、文件、工具和代码执行环境。它有桌面 GIS 前端、Sidecar 后端、工具系统、operation、skill、worker、memory、context projector、capability router、run archive 和 prompt cache。我们先对这组基础设施做一个简要说明：
| 术语 | 中文解释 | 在 OpenGIS 中的角色 |
|---|---|---|
| Sidecar | 伴随服务端 | 随桌面端启动的 FastAPI 后端，负责 RPC、流式对话、代码执行和工作区状态管理 |
| Operation | 原子操作 | 可执行、可参数化、可验证的 GIS 分析单元，适合沉淀稳定能力 |
| Skill | 技能文档 | 面向 Agent 的经验说明、流程规则或领域知识包 |
| Worker | 驻守进程 | 长时间运行的后台 Python 应用，用于持续数据采集、动态地图更新等任务 |
| Memory | 记忆 | 会话内外的结构化经验、事实、失败教训和用户纠正 |
| Context Projector | 上下文投影器 | 把工作区状态、记忆和能力资产压缩成模型可读的上下文 |
| Capability Router | 能力路由器 | 根据任务选择少量相关 tool、skill、operation，避免上下文膨胀 |
| Run Archive | 运行归档 | 保存每轮任务的消息、工具调用、代码执行、错误、产物和指标 |
| Prompt Cache | 提示词缓存 | 通过稳定 prompt 前缀提升供应商侧缓存命中率，降低重复输入成本 |
这里的 Agent Harness，指的是包裹在大模型外侧的工程系统：提示词组织、上下文裁剪、工具暴露、执行循环、记忆管理、评估器、权限边界和能力资产管理。模型本体并不直接知道文件系统、地图状态、图层样式、工作区结构和历史任务，它必须通过 harness 才能感知环境、调用工具、执行代码、观察结果并收束任务。
因此，OpenGIS 的自进化也不应被理解为“训练模型”或“自动改核心代码”。它更准确的定义是：
在固定模型、固定工具实现、固定执行环境下，OpenGIS 从历史 run archive 中提取失败模式、成功流程和用户纠正信号，生成候选能力；候选经过 replay、held-in / held-out 检查和 promotion gate 后，被物化为 skill、operation、prompt_patch 或 tool_policy；运行时由 CapabilityRouter 按需选择少量资产注入或暴露，并支持禁用与回滚。
我们需要明确以下三点：
- 第一，进化仅面向 OpenGIS harness 本身，和模型隔离。
- 第二，不直接改 active harness 骨架。Active Harness（当前生效的运行框架）包括 loop kernel、核心 system prompt、权限系统、provider adapter、verifier 和核心渲染逻辑。它是生产运行时，不应该被候选能力在线改写。否则系统很容易通过改评估器、调大预算、绕过权限来刷分，并有可能生成我们不希望的产物。
- 第三，进化产物必须是受控资产。OpenGIS 允许沉淀 skill、operation、prompt_patch、tool_policy 或 workflow，但这些资产应先进入 draft 或 review 状态，经评估或用户批准后启用。启用后如果造成回归，应能立即禁用或回滚。
OpenGIS 已具备的基础设施
OpenGIS 已经具备自进化所需要的若干底座，我们依次介绍：
运行归档层负责把一次任务转成可分析的轨迹。RunArchive 保存用户输入、Agent 输出、工具调用、代码执行、错误、产物路径、token 消耗和终止原因。可以说没有运行归档，自进化就没有证据来源。
上下文构造层负责把工作区状态、会话记忆、工具 schema、能力资产和用户目标组织成 provider request，包含ProviderRequestBuilder、ContextProjector、RequestBudgetManager 和 ToolMaterializer 等用于编排模型请求的组件。
工具执行层负责把模型的意图转成可控动作。ToolRuntime、operation、workflow、worker、map RPC 和 datasource tool 共同构成了 Agent 的外部执行面。它们既是任务执行工具，也是未来可优化的对象。
记忆与经验层负责从运行记录中抽取可复用知识。MemoryStore、KnowledgeExtractor、FailureMemoryExtractor 和结构化 failure memory 可以记录用户纠正、失败修复和高频经验。
能力路由层负责在运行时选择少量相关能力。CapabilityRouter 和 tool pack 机制用于避免所有工具、所有 skill、所有 operation 同时进入上下文。这个模块对 token 成本、prompt cache 命中率和注意力稀释都非常关键。
自进化闭环
OpenGIS 自进化不是单纯的：
这只是记忆系统。真正的自进化闭环应该是：
对应到 OpenGIS 的工程模块，可以表示为：
1 | RunArchive |
其中，
RunArchive 是运行归档，负责提供原始证据。
WeaknessMiner 是弱点挖掘器，负责从轨迹中发现高频失败、重复纠正和无意义绕路。
EvolutionExtractor 是候选提取器，负责把原始轨迹转成结构化候选。
ReplayEvaluator 是回放评估器，负责在隔离环境中验证候选是否有效。
PromotionGate 是晋升门，负责决定候选是否可以进入可用资产。
EvolutionMaterializer 是物化器，负责把候选落成 skill、operation、prompt_patch 或 tool_policy。
EvolutionAssetRegistry 是资产注册表，负责记录资产来源、版本、状态、评估结果和启用范围。
CapabilityRouter 是能力路由器，负责在后续任务中按需选择少量相关资产。
这条链路强调两件事：候选生成要积极，候选启用要保守。系统可以从大量历史轨迹中发现潜在改进，但不能把所有候选都直接塞进运行时。
当前实现状态
OpenGIS 当前已经初步具备自进化链路中的关键组件：
| 模块 | 作用 | 当前状态 |
|---|---|---|
| Run Archive | 保存完整运行轨迹 | 已具备 |
| Failure Memory | 抽取失败和纠正经验 | 已具备 |
| Evolution Extractor | 从轨迹生成候选能力 | 已具备初版 |
| Weakness Miner | 聚合高频失败与纠正模式 | 已具备初版 |
| Replay Evaluator | 回放验证候选收益 | 已具备初版 |
| Promotion Gate | 控制候选晋升 | 已具备初版 |
| Materializer | 将候选物化为资产 | 已具备初版 |
| Asset Registry | 管理进化资产状态 | 已具备初版 |
| Evolution Reporter | 汇总候选、评估和资产状态 | 已具备初版 |
| Headless CLI | 脚本化运行 Agent 与 benchmark | 已具备初版 |
但这些模块还只是形成了自进化框架的第一版。它已经可以证明“轨迹可以转成候选，候选可以评估并物化”，但距离稳定的 benchmark 级自进化系统还有几个缺口：
- GABench 任务还需要更严格的 artifact verifier；
- canonical action 轨迹评分还需要更完整；
- promotion gate 需要更强的成本回归判断；
- evolution dashboard 需要展示更清楚的资产收益、回归和回滚状态；
- 评估报告需要区分成功率提升、成本下降和无回归三类结果。
OpenGIS 自进化系统的核心概念
图1：OpenGIS 自进化基础框架
OpenGIS 自进化系统可以从四个问题理解：由谁优化、优化什么、如何优化、怎样评估。对应英文概念分别是 Optimizer、Optimization Target、Optimization Path 和 Evaluation Metrics。
Optimizer
Optimizer，优化器 是 OpenGIS 内部由多模块组成的治理链路，它的输入是历史运行轨迹，输出是经过验证的能力资产。这条治理链路的关键是基于证据提出建议，并基于评估拒绝或采纳建议。这点很重要，因为自进化系统最容易失控的地方不是不会生成候选，而是生成太多看起来合理、实际带来负担的候选。
例如，一个泛化 recipe skill 可能会告诉 Agent：“进行 GIS 分析时要先检查字段、检查 CRS、检查输出路径，再验证结果。”这句话单看没有问题。但如果它导致每个简单任务都全量执行上述操作，它就不是正收益资产。因此，OpenGIS 的优化器可以概括为：
以运行轨迹为证据、以回放评估为约束、以资产注册为边界的 harness 层优化链路。
Optimization Target
Optimization Target，优化对象定义哪些东西可以被自进化系统修改，哪些东西不能被自动修改，允许优化的对象包括：
| 对象 | 中文解释 | 适合优化的原因 |
|---|---|---|
skill |
技能文档或任务经验包 | 适合沉淀流程规则、错误规避和领域经验，成本低，易禁用 |
operation |
可执行的原子 GIS 操作 | 适合沉淀稳定代码、输入输出 contract 和可复用分析流程 |
prompt_patch |
局部提示词补丁 | 适合修正某类局部行为，例如“不要绕过失败 operation” |
tool_policy |
工具选择策略 | 适合调整工具包暴露、工具优先级和重复调用抑制 |
workflow |
多步骤任务编排 | 适合沉淀高频、稳定、跨任务复用的分析链路 |
而不应被自进化系统在线自动修改的对象包括：
| 对象 | 中文解释 | 不自动修改的原因 |
|---|---|---|
| Core System Prompt | 核心系统提示词 | 这是行为宪法，在线自改容易造成全局行为漂移 |
| Loop Kernel | 执行循环内核 | 影响工具调用、终止条件和状态一致性，风险过高 |
| Permission Model | 权限模型 | 不能为了提高任务成功率绕过用户批准或文件安全边界 |
| Verifier | 验证器 | 如果 Agent 能改验证器，就可能通过降低标准“刷分” |
| Provider Adapter | 模型供应商适配层 | 涉及消息协议、tool call 格式和缓存统计，属于基础设施 |
| Renderer Core | 地图渲染核心 | 影响前端稳定性，不应由经验候选直接改写 |
这是一条必要的安全边界。OpenGIS 的自进化不应该是系统改自己的一切，而应该是在一个受控编辑面内积累能力。重要的是，越靠近运行时骨架，越需要人工 review、测试和版本管理；越靠近 skill / operation / policy 资产，越适合自动提出、自动评估和半自动启用。
Optimization Path
Optimization Path，优化路径描述一次经验如何从任务轨迹变成可复用能力。
完整路径如下：
1 | 历史运行轨迹 |
held-in 指与候选来源相近、用于验证候选是否修复原问题的任务集合。它回答的是：这个候选有没有修好它声称要修的问题。
held-out 指候选生成时没有参与的留出任务集合。它回答的是：这个候选有没有破坏其他任务。自进化系统如果没有 held-out，很容易出现“修好 A，破坏 B”的情况。
cost regression 指成本回归，也就是启用资产后虽然成功率可能提高，但 token、LLM turn、工具调用、耗时或 warning 变多。对 OpenGIS 这种本地桌面 Agent 来说，成本不只是钱，也包括等待时间、上下文压力和前端状态复杂度。
这个流程中最重要的分离是：候选生成和候选启用必须分开。系统可以积极生成候选，但必须保守启用候选。候选如果没有清晰证据、没有重复支撑、没有回放收益、没有留出集验证，就只能停留在 draft 或 review 状态，不能进入 active runtime。
Evaluation Metrics：自进化必须同时看收益、成本和回归
Evaluation Metrics，评估指标决定系统能不能证明自己真的在变好。自进化评估不能只看任务是否成功。一个资产如果让成功率从 80% 提高到 100%，但平均 token 翻倍、工具调用增加、cache hit rate 下降，那么它可能只是让 Agent 更努力，而不是让 Agent 更聪明。由此，OpenGIS 的评估指标分成四层。
这套指标的判断标准可以概括为一句话：
有效自进化必须带来可归因收益，并且不显著增加成本、不破坏留出任务、不污染运行时上下文。
核心术语表
| 术语 | 中文解释 | 在 OpenGIS 中的含义 |
|---|---|---|
| Agent | 智能体 | 基于大模型、工具调用和执行反馈完成 GIS 任务的运行主体 |
| Harness | 智能体工程外壳 / 运行框架 | 大模型外侧的 prompt、context、tool、loop、memory、policy、verifier 等工程系统 |
| Active Harness | 当前生效的运行框架 | 正在服务用户任务的生产运行时，不应被自进化系统直接在线改写 |
| Run Archive | 运行归档 | 每轮任务的消息、工具、代码、错误、产物和指标记录 |
| Weakness Mining | 弱点挖掘 | 从失败、纠正和重复绕路中发现可优化模式 |
| Candidate | 候选能力 | 尚未被采纳的改进提案 |
| Replay | 回放评估 | 在隔离环境中复现任务，用于验证候选是否有效 |
| Held-in | 域内验证集 | 与候选来源相近、用于验证候选是否修复原问题的任务集合 |
| Held-out | 留出验证集 | 未参与候选生成、用于检查回归的任务集合 |
| Promotion Gate | 晋升门 | 决定候选是否可以进入可用资产的评估与治理模块 |
| Materialization | 物化 | 把候选转成 skill、operation、prompt_patch 或 tool_policy 等具体资产 |
| Asset Registry | 资产注册表 | 管理进化资产版本、状态、来源和启用范围的 registry |
| Capability Router | 能力路由器 | 按当前任务选择少量相关 tool、skill、operation 或 policy |
| Skill | 技能 | 以文档形式沉淀的任务经验、操作规则或领域知识 |
| Operation | 原子操作 | 具备输入输出 contract、可执行、可验证、可复用的 GIS 程序单元 |
| Prompt Patch | 提示词补丁 | 局部行为修正规则，不改核心 system prompt |
| Tool Policy | 工具策略 | 工具选择、优先级、暴露范围和重试行为的建议策略 |
| Cost Regression | 成本回归 | 启用资产后 token、turn、tool call、耗时或 warning 变差 |
| No-regression | 无回归 | 新资产没有破坏 held-out 或其他既有任务能力 |
| Prompt Cache Hit Rate | 提示词缓存命中率 | provider 侧复用相同 prompt 前缀 token 的比例 |
自进化实验设计
实验目标、数据集与实验设计
实验动机
普通 benchmark 评估的是：
这次任务做对了吗？
而 OpenGIS 自进化实验要评估的是：
系统是否能从任务历史中产生能力，并且这些能力在后续任务中被验证为有用？
这两个问题差别很大。前者评估的是一次输出，后者评估的是一个运行时系统是否具备自我改进能力。如果一次任务失败了，系统能不能记住失败？如果同类失败反复出现，系统能不能把它抽象成一个可复用修复？如果某段代码或某个分析流程反复有效，系统能不能把它沉淀为 operation 或 skill？更重要的是，这些沉淀下来的能力是否真的让之后的任务更好，而不是只是把上下文变长、把 token 变贵？这就是本文实验设计要回答的问题，检验 OpenGIS 能否基于真实 GIS 任务轨迹完成受控自进化。
数据集介绍
评估与优化过程采用 GABench Data 数据集（https://huggingface.co/datasets/zhangdw/GABench）。GABench 用于评估 Agent 在真实 GIS 分析任务中的表现。这些任务综合了自然语言指令、地理空间数据图层、工具链规划，以及生成的地图或表格输出等多个方面。它的任务天然包含 GIS 执行链：数据读取、字段检查、CRS 处理、空间分析、栅格处理、制图渲染、结果导出与参考产物，共53条，包括16组栅格空间分析，13组地统计，11组水文分析等，例如基于温度点数据做 Kriging 插值，并结合老年人口密度识别高风险区域。
GABench 到 OpenGIS 的语义映射
OpenGIS 的工具体系（operation、skill、tool）与 GABench 参考工具链不同，不能要求工具名一致。通过 Canonical Action（标准语义动作） 把不同工具实现映射到同一类 GIS 语义动作，避免把语义等价但工具不同的执行路径误判为失败。
| Canonical Action | 中文解释 | OpenGIS 中可能的实现 |
|---|---|---|
inspect_dataset |
检查数据 | read_file、get_layer、get_raster_info、query_features |
vector_analysis |
矢量分析 | run_operation、受控 execute_code |
raster_analysis |
栅格分析 | run_operation、受控 execute_code |
load_vector |
加载矢量图层 | add_layer、operation 输出后 add_layer |
load_raster |
加载栅格图层 | add_raster |
style_vector |
设置矢量样式 | update_layer_style、set_categorized_style |
style_raster |
设置栅格样式 | set_raster_style |
export_artifact |
导出结果产物 | 写出 GeoJSON / CSV / JSON / TIFF / PNG |
verify_output |
验证输出 | artifact verifier、schema check、空间统计 check |
任务切分
GABench 任务量不大，实验切分分三层：
- Held-in（域内验证集）：候选能力的来源，典型弱点包括参数错误、CRS warning、operation contract 缺失、输出已生成但 loop 不收口、用 Python 绕过已有工具、重复 list/read/check。
- In-domain Held-out（同域留出集）：同领域不同任务，测同类泛化。
- Cross-domain Transfer（跨域迁移集）：跨 GIS 领域（vector→raster、制图→空间统计），检查资产是否过拟合任务域。
实验臂设计
| 实验臂 | 含义 | 目的 |
|---|---|---|
| Static Baseline | 静态基线，不启用自进化资产 | 得到基础成功率、token、turn、工具调用 |
| Routed Baseline | 启用 CapabilityRouter，不启用资产 | 分离工具路由收益 |
| Skill-only Evolution | 只允许 skill 资产启用 | 看流程经验是否有用 |
| Operation Evolution | 允许 operation 资产启用 | 看代码/分析能力复用收益 |
| Policy Evolution | 允许 prompt_patch / tool_policy | 看工具选择策略是否改善 |
| Full Evolution | skill + operation + policy 全启用 | 看完整系统收益 |
自进化闭环执行机制
轨迹采集
每个 task-run 完整归档：user prompt、provider request 摘要、selected tool packs、selected skills / operations / evolution assets、tool call name / args / result、code step、warning / error / retry、artifact path、final answer、LLM turn、prompt / completion / cached tokens、wall time、loop termination reason。这些不是调试日志，而是自进化系统的训练材料。
候选生成
候选来自三类信号：
- 失败信号：tool 参数缺失、operation
KeyError、raster style 参数不匹配、layer id 失效、CRS / geometry warning、timeout、API connection error。关键是错误后是否出现修复路径（如edit_operation -> run_operation success），这类轨迹比单纯失败更有价值。 - 纠正信号：用户直接反馈（“不要用 Python 设置样式，用 style tool”“输出已生成，为什么还不停止”），权重高于普通成功轨迹，直接暴露 harness 行为偏差。
- 复用信号：多次成功的工具序列、代码片段或 operation，且降低成本，才算能力。
候选必须包含来源 run、触发原因、目标组件、证据、拟议修改、验证方式和适用边界。"道路缓冲区分析要先投影到米制 CRS"是候选能力；"这次做了道路分析"不是。
晋升门槛
自进化的核心不是会生成候选，而是会拒绝候选。Promotion Gate 包含三类门槛：
- 质量门槛：候选需具备 evidence、target component、proposed change、replay case、held-out check 和回滚路径；无复用意图、无重复支撑的泛化 recipe 只能停留在 review。
- 收益门槛：启用后至少一项正收益（success rate / artifact correctness 上升，或 token / turn / tool call / retry / warning 下降）；成功率提高但 token 大涨标记为 cost regression。
- 回归门槛：不得造成 held-out 成功率下降、token / tool call 持续上升、warning 增多、无关任务被错误路由、prompt cache hit rate 明显下降。
实验流程
1 | Checkpoint 0: static baseline |
成功判据与初步实验结果
成功判据
- 任务成功率不下降；
- held-out 无明显回归；
- 至少一个启用资产带来可归因正收益；
- token 或 turn 至少一个成本指标下降；
- 负收益资产能被拒绝或回滚；
- 资产不会无限膨胀进入上下文。