admin/claw

Files

木炎 630190e4d3 docs: add command center analysis artifacts

Capture the command-center operation analyses, inventory outputs, and browser pipeline reference files produced during the current research pass so they can be reviewed from the branch.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-04-09 10:43:09 +08:00

19 KiB

Raw Blame History

指挥中心虚拟员工标准配置清单建议结构

免责声明：本文件描述的是“未来可采用的规范化目标配置结构”，不是当前 staged runtime 已稳定实现的结构，也不是对现状的直接复述。文中所有“目标 schema 字段”都必须与当前证据分级文档一起阅读；凡缺乏静态资产直接支撑的字段，只能视为 normalization choice 或 open / candidate 字段，不能表述为当前已稳定存在。

目标

这份结构文档的用途，是把当前 evidence-graded 现状文档中的信息，逐步映射为后续可维护、可扩展、可复用的目标配置清单。

因此必须同时保持两条边界：

当前已观察到的事实，来自 evidence-graded current-state docs。
这里提出的统一 schema，则是为后续 command-center 配置治理而做的 normalization proposal。

它们不能混写，更不能把 normalization proposal 误写成当前实现事实。

一、当前证据文档与目标配置的关系

当前已经存在三类文档角色：

2026-04-08-command-center-virtual-employee-inventory-table.md
- 作用：给人读的 current-state 总览
- 性质：当前观察结果，不是配置 schema
2026-04-08-command-center-virtual-employee-inventory.json
- 作用：给机器读的 current-state inventory
- 性质：机器可消费的盘点结果，不是目标配置
各 scene 的 *-operation-analysis.md
- 作用：记录每个场景的证据来源、强弱、已知问题和边界
- 性质：最关键的证据支撑层

本文件提出的目标配置结构，是在这些 current-state 文档之上的“规范化目标层”。

映射原则

operation-analysis 文档中的 code-confirmed 结论，可优先映射为目标 schema 中的“evidence-derived fields”。
contract-defined 结论，可映射为“declared / contract-backed fields”，但不能默认等于当前 runtime 已实现。
implementation intent exists but not rigorous / buggy 的内容，应进入目标 schema 的 known_issues、implementation_gap、notes 或 open_questions，而不是被包装成稳定主字段。
no direct evidence / candidate only 的内容，只能作为 normalization choice、candidate field 或未来扩展项保留。

简言之：evidence-graded current-state docs 告诉我们“现在能严谨说什么”，本文件只负责说明“未来若要统一配置，可怎样承接这些信息”。

二、推荐文件组织

command-center/
  employee.json
  capabilities.json
  tasks/
    fault-details-report.json
    jinchang-business-environment-weekly-report.json
    95598-weekly-monitor-report.json
    95598-repair-city-dispatch.json
    jiayuguan-meter-outage.json

文件职责

employee.json
- 描述这个虚拟员工是谁、职责范围是什么、默认采用什么证据口径
capabilities.json
- 维护归一化能力词表
- 明确哪些能力来自现有证据，哪些只是规范化命名
tasks/*.json
- 每个场景一份目标配置
- 承接当前证据与未来标准字段的映射关系

为什么仍然推荐三层拆分

这类拆分仍然成立，但要加一条限定：

这是一种 target architecture proposal
不是当前仓库已存在的稳定目录结构
尤其 capabilities.json 代表“统一能力词表”的目标态，而不是当前 staged assets 已实现的统一能力注册表

因此，三层拆分本身属于 normalization choice，证据等级不应高于 no direct evidence / candidate only，除非未来真的落地成文件结构。

三、`employee.json` 目标结构

3.1 推荐示例

{
  "id": "command-center-virtual-employee",
  "name": "指挥中心虚拟员工",
  "domain": "电力业务指挥中心",
  "positioning": "负责业务监测、统计报表、异常识别与后续提醒/处置支撑的虚拟运营员工",
  "mission": [
    "采集业务数据并生成结构化报表",
    "监测工单/事件并识别待处理对象",
    "比较历史记录识别新增待办",
    "为提醒、外呼、自动派单、自动处理等下游动作提供输入"
  ],
  "task_ids": [
    "fault-details-report",
    "jinchang-business-environment-weekly-report",
    "95598-weekly-monitor-report",
    "95598-repair-city-dispatch",
    "jiayuguan-meter-outage"
  ],
  "default_evidence_model": [
    "code-confirmed",
    "contract-defined",
    "implementation intent exists but not rigorous / buggy",
    "no direct evidence / candidate only"
  ],
  "default_status_model": [
    "success",
    "partial",
    "empty",
    "blocked"
  ]
}

3.2 字段分层说明

A. 可直接由当前证据承接的字段

name
domain
task_ids（前提是仅映射当前已盘点的 5 个 scene）
default_evidence_model

这些字段之所以较容易承接，是因为 current-state inventory 已经稳定整理出对应对象和场景清单。

但仍要注意：这只是“可从当前文档整理得到”，不是说仓库里已经存在一个运行中的 employee.json。

B. normalization choices

id
positioning
mission
default_status_model

这些字段主要是为了让目标配置更易治理、更可复用，属于规范化整理，不应表述为 staged runtime 现状。

C. open / candidate 字段

建议预留但暂不稳定化：

default_runtime_requirements
default_result_types
default_downstream_policy
org_scope
region_scope

原因是：当前不同 scene 在“上下文依赖、输出类型、地区语义、下游策略”上并不一致，过早把这些做成员工级稳定字段会拔高现状。

四、`capabilities.json` 目标结构

4.1 推荐示例

{
  "catalog_version": 1,
  "evidence_method": "evidence-graded",
  "core": [
    {
      "id": "browser-collection",
      "name": "浏览器采集",
      "kind": "normalized-capability",
      "evidence_basis": "derived-from-multiple-scenes"
    },
    {
      "id": "report-generation",
      "name": "报表生成",
      "kind": "normalized-capability",
      "evidence_basis": "derived-from-report-scenes"
    },
    {
      "id": "monitor-snapshot",
      "name": "监测快照",
      "kind": "normalized-capability",
      "evidence_basis": "derived-from-monitor-scenes"
    }
  ],
  "channels": [
    {
      "id": "audio-remind",
      "name": "音频提醒",
      "kind": "normalized-channel",
      "observed_in": [
        "95598-repair-city-dispatch",
        "jiayuguan-meter-outage"
      ]
    },
    {
      "id": "message-remind",
      "name": "消息提醒",
      "kind": "normalized-channel",
      "observed_in": [
        "95598-repair-city-dispatch"
      ],
      "notes": "在 jiayuguan-meter-outage 中只看到保留意图，不应等同视为稳定现状。"
    }
  ],
  "actions": [
    {
      "id": "auto-dispatch",
      "name": "自动派单",
      "kind": "normalized-action"
    }
  ]
}

4.2 字段分层说明

A. 可由当前证据承接的字段

observed_in
notes
evidence_basis

如果后续真的落地 capabilities.json，最应该优先保留的不是“能力名本身”，而是能力和 scene 之间的 evidence mapping。因为当前场景的能力证据强弱明显不同：

3 个报表 scene 多为 schema/template stub
2 个监测 scene 更强 workflow 主要来自规则资产
message-remind、callout、auto-dispatch 等通道在不同 scene 中强度不一致

B. normalization choices

core
channels
actions
id
name
kind

这些统一词表字段本身就是规范化选择。当前没有直接证据表明仓库中已经存在统一 capability registry。

C. open / candidate 字段

建议保持候选态：

required_contexts
result_semantics
stability_level
implemented_by
runtime_owner

这些字段看起来很有用，但 staged assets 还不足以稳定支撑它们。

4.3 对能力词表的关键限制

不要把 report-export、audio-remind、callout 之类词条本身写成“已全局统一支持”。
不要因为某个规则资产里出现了调用，就把它提升为所有 scene 的稳定 capability。
email 目前仍应保持 candidate，不应进入“已支持通道”集合。

五、`tasks/*.json` 目标结构

5.1 统一推荐骨架

{
  "id": "95598-repair-city-dispatch",
  "name": "95598抢修-市指",
  "category": "monitor",
  "current_state": {
    "primary_evidence_summary": "rule assets stronger than packaged JS stub",
    "source_refs": [],
    "known_issues": []
  },
  "binding": {
    "scene_id": "95598-repair-city-dispatch",
    "skill_package": "95598-repair-city-dispatch",
    "tool": "collect_repair_orders"
  },
  "trigger": {
    "observed": {},
    "normalized": {},
    "open_questions": []
  },
  "inputs": {
    "observed": {},
    "normalized": {},
    "open_questions": []
  },
  "systems": {
    "observed": {},
    "normalized": {},
    "open_questions": []
  },
  "workflow": {
    "observed": [],
    "normalized": [],
    "open_questions": []
  },
  "result": {
    "observed": {},
    "normalized": {},
    "open_questions": []
  },
  "downstream_effects": {
    "observed": [],
    "normalized": [],
    "open_questions": []
  },
  "required_capabilities": {
    "normalized": [],
    "open_questions": []
  },
  "status_model": {
    "declared": {},
    "implemented_notes": []
  },
  "evidence_grades": {},
  "open_questions": []
}

这个骨架的核心目标不是“把所有字段都填满”，而是强制区分：

observed
normalized
open_questions

这样可避免把 future-facing target config 误写成 current-state。

六、报表类任务在目标 schema 中应如何表达

适用对象：

fault-details-report
jinchang-business-environment-weekly-report
95598-weekly-monitor-report

6.1 当前证据对目标 schema 的约束

这 3 个任务当前最强直接证据主要是：

已有 report-artifact 结构壳
已有 section/template 定义
已有 status / partial_reasons 字段壳

但它们共同缺少同等强度的 live collection 证据。因此若采用该目标 schema，建议保留一个明确的 current-state 提示，例如：

"current_state": {
  "primary_evidence_summary": "packaged script mainly confirms artifact schema / section template; live collection remains contract-defined or weaker"
}

6.2 报表类字段分层

A. evidence-derived fields

binding.scene_id
binding.skill_package
binding.tool
result.observed.artifact_type
result.observed.key_fields
systems.observed.browser_pages
source_refs

B. normalization choices

trigger.normalized.natural_language_examples
inputs.normalized.runtime_context
workflow.normalized
required_capabilities.normalized
downstream_effects.normalized

C. open / candidate fields

period_model
section_semantics
region_scope
alignment_rule
report_export_policy

6.3 各报表任务的特别约束

`fault-details-report`

若采用该目标 schema，建议对外保留 period，但执行层最好允许展开为 startTime/endTime。
summary-sheet 建议标记为“template confirmed”，不要误写成“summary derivation implemented”。

`jinchang-business-environment-weekly-report`

若采用该目标 schema，建议把“4 个固定 section 模板已观察到”与“真实多源采集已实现”分开表达。
region 是否成为稳定字段，目前仍是 open item。

`95598-weekly-monitor-report`

若采用该目标 schema，建议预留 currentPeriod 与 cumulativePeriod，但必须注明这属于对当前建模冲突的修正提案。
period alignment 建议单列为 schema group 或 alignment_rule，而不是默认已经在 runtime 中稳定存在。

七、监测类任务在目标 schema 中应如何表达

适用对象：

95598-repair-city-dispatch
jiayuguan-meter-outage

7.1 当前证据对目标 schema 的约束

这两个任务与报表类不同：

packaged JS collector 已具备输入驱动的 monitor-snapshot 归一化 / 比较逻辑，并会附带规则来源、配置基础页角色、已知问题/身份模型说明
更强 workflow 证据主要来自规则资产（当前按盘点口径以 D:/desk/智能体资料/大四区报告监测项/*.txt 规则脚本为主）
assets/scene-snapshot/index.html 仅属于配置基础层，不应计入 workflow 主执行证据

因此若采用该目标 schema，建议显式区分：

"current_state": {
  "packaged_stub_strength": "code-confirmed",
  "rule_asset_workflow_strength": "code-confirmed",
  "notes": "workflow evidence is stronger in rule assets than in packaged JS stub"
}

7.2 监测类字段分层

A. evidence-derived fields

binding.*
inputs.observed.explicit
systems.observed.upstream_apis
systems.observed.local_services
workflow.observed
result.observed
downstream_effects.observed
current_state.known_issues

B. normalization choices

workflow.normalized
required_capabilities.normalized
canonical_snapshot_fields
effect_channels

C. open / candidate fields

identity_model
downstream_policy
alert_channel_split
auto_processing_policy
dependency_promotion_rules

7.3 各监测任务的特别约束

`95598-repair-city-dispatch`

若采用该目标 schema，建议保留以下说明：

workflow 强证据主要来自规则资产（当前盘点以 D:/desk/智能体资料/大四区报告监测项/95598抢修-市指_业务检测配置.txt 与 D:/desk/智能体资料/大四区报告监测项/95598抢修-市指_自动处理配置.txt 为主），而不是 packaged JS stub
pending 分类存在 status == "00" && status == "01" bug
pending_ids/new_pending_ids 更像 canonical target fields，而不是当前规则层已严格同名产出字段

建议把这个 bug 直接纳入：

"current_state": {
  "known_issues": [
    "pending classification bug: status == \"00\" && status == \"01\""
  ]
}

`jiayuguan-meter-outage`

若采用该目标 schema，建议保留以下说明：

workflow 强证据主要来自规则资产（当前盘点以 D:/desk/智能体资料/大四区报告监测项/户表失电-嘉峪关_业务监测配置.txt 与 D:/desk/智能体资料/大四区报告监测项/户表失电-嘉峪关_自动处理配置.txt 为主），而不是 packaged JS stub
marketing token 是自动处理链路的强依赖
monitor pending list 用 consNo，dispose dedupe 用 eventId，身份模型不一致

因此在该目标 schema 提案中，建议单列：

"identity_model": {
  "monitor_pending_identity": "consNo",
  "dispose_dedupe_identity": "eventId",
  "status": "implementation intent exists but not rigorous / buggy"
}

这类字段不应被伪装成“已经统一好的 snapshot identity model”。

八、推荐统一字段清单与证据边界

下面给出一个更严格的统一字段视图。

1. 元数据层

较适合作为稳定 target schema 的字段：

id
name
category
binding.scene_id
binding.skill_package
binding.tool

其中：

binding.* 更偏 evidence-derived
id/name/category 更偏 normalization choice

2. 现状映射层

建议新增并长期保留：

current_state.primary_evidence_summary
current_state.source_refs
current_state.known_issues
current_state.notes

这是本次重写后最重要的新增设计点之一。没有这层，target schema 很容易再次把“目标结构”和“现状证据”混在一起。

3. 触发层

trigger.observed
trigger.normalized
trigger.open_questions

4. 输入层

inputs.observed
inputs.normalized
inputs.open_questions

5. 系统层

systems.observed
systems.normalized
systems.open_questions

6. 流程层

workflow.observed
workflow.normalized
workflow.open_questions

7. 结果层

result.observed
result.normalized
result.open_questions

8. 下游动作层

downstream_effects.observed
downstream_effects.normalized
downstream_effects.open_questions

9. 能力层

required_capabilities.normalized
required_capabilities.open_questions

10. 证据层

evidence_grades
source_refs

11. 人工确认层

open_questions
known_issues

九、为什么这次建议在 target schema 中显式保留“现状层”

旧版结构容易出现的问题是：

把 aggregate inventory 直接写成“标准配置已经长这样”
把 required_capabilities、downstream_effects 这样的归一化字段误读成 runtime 现状
把规则资产中的 workflow 直接等价成 packaged script 实现

因此这次建议最关键的修订不是多加几个字段，而是要求 target schema 同时携带：

observed current state
normalized target structure
open / candidate items

只有这样，后续继续扩展新 scene 时，文档才不会再次把三类内容混在一起。

十、建议的落地顺序

先把 current-state inventory 保持为证据分级后的事实盘点。
再基于 inventory 生成目标态 employee.json / capabilities.json / tasks/*.json 草案。
落地草案时，强制为每个 major group 补齐：
- observed
- normalized
- open_questions
先优先收敛已知关键不严谨点：
- fault-details-report 的 period vs startTime/endTime
- 95598-weekly-monitor-report 的双周期 / period alignment
- 95598-repair-city-dispatch 的 pending classification bug
- jiayuguan-meter-outage 的 consNo vs eventId 身份不一致
最后再考虑是否把能力词表与 target config 接入真实消费链路。

注意：在这些问题未收敛前，不应把目标配置字段写成“已经稳定”。

十一、推荐结论

如果目标是形成“指挥中心虚拟员工的标准配置清单”，那么未来仍然可以采用：

employee.json
capabilities.json
tasks/*.json

这样的三层结构。

但和旧版不同的是，这套结构必须显式承认：

它是 target architecture proposal，不是现状复述
每个 major schema group 都要区分 evidence-derived fields、normalization choices、open / candidate fields
evidence-graded current-state docs 才是现状依据
报表类 3 个 scene 当前主要是 schema/template stub
95598-repair-city-dispatch 与 jiayuguan-meter-outage 的 workflow 强证据主要在规则资产
95598-repair-city-dispatch 存在 pending classification bug
jiayuguan-meter-outage 存在 consNo / eventId 身份不一致问题
任何地方都不应宣称 runtime verification

只有在保持这些边界的前提下，这份“标准配置结构”才是严谨可持续的目标态提案，而不是再次把现状、推断和目标混写在一起。

19 KiB Raw Blame History Unescape Escape

指挥中心虚拟员工标准配置清单建议结构

目标

一、当前证据文档与目标配置的关系

映射原则

二、推荐文件组织

文件职责

为什么仍然推荐三层拆分

三、employee.json 目标结构

3.1 推荐示例

3.2 字段分层说明

A. 可直接由当前证据承接的字段

B. normalization choices

C. open / candidate 字段

四、capabilities.json 目标结构

4.1 推荐示例

4.2 字段分层说明

A. 可由当前证据承接的字段

B. normalization choices

C. open / candidate 字段

4.3 对能力词表的关键限制

五、tasks/*.json 目标结构

5.1 统一推荐骨架

六、报表类任务在目标 schema 中应如何表达

6.1 当前证据对目标 schema 的约束

6.2 报表类字段分层

A. evidence-derived fields

B. normalization choices

C. open / candidate fields

6.3 各报表任务的特别约束

fault-details-report

jinchang-business-environment-weekly-report

95598-weekly-monitor-report

七、监测类任务在目标 schema 中应如何表达

7.1 当前证据对目标 schema 的约束

7.2 监测类字段分层

A. evidence-derived fields

B. normalization choices

C. open / candidate fields

7.3 各监测任务的特别约束

95598-repair-city-dispatch

jiayuguan-meter-outage

八、推荐统一字段清单与证据边界

1. 元数据层

2. 现状映射层

3. 触发层

4. 输入层

5. 系统层

6. 流程层

7. 结果层

8. 下游动作层

9. 能力层

10. 证据层

11. 人工确认层

九、为什么这次建议在 target schema 中显式保留“现状层”

十、建议的落地顺序

十一、推荐结论

19 KiB

Raw Blame History

三、`employee.json` 目标结构

四、`capabilities.json` 目标结构

五、`tasks/*.json` 目标结构

`fault-details-report`

`jinchang-business-environment-weekly-report`

`95598-weekly-monitor-report`

`95598-repair-city-dispatch`

`jiayuguan-meter-outage`