🔍 事件影响分析 Agent

1 设计哲学

借鉴 OpenClaw 的 Skill 架构模式：Agent 本身只负责推理，所有外部能力通过 Skill 注入。

我们的事件影响分析系统完全复用这个模式：

block-beta
  columns 1
  block:agent["Event Impact Agent"]:1
    columns 3
    sp["System Prompt\n推理框架 + 输出规范"]
    sk["Skills\nknowledge-graph\nevent-decomposer\nimpact-reasoner"]
    llm["LLM\nClaude / GPT"]
  end
    

2 系统架构

2.1 整体架构

flowchart TB
    U["👤 用户输入事件"] --> AC

    subgraph AC["Agent Controller · 会话管理 + Skill 调度"]
        direction TB
        S1["🧩 knowledge-graph\n图谱查询能力"]
        S2["🧩 event-decomposer\n事件结构化拆解"]
        S3["🧩 impact-reasoner\n影响链推理"]
        SP["📋 System Prompt\n角色定义 · 推理框架 · 输出规范"]
    end

    AC -->|"Skill 内部通过 CLI/API 调用"| KG

    subgraph KG["Knowledge Graph Service · REST API"]
        direction LR
        A1["/api/search"]
        A2["/api/entity/{id}"]
        A3["/api/relations"]
        A4["/api/path"]
        A5["/api/industry"]
        A6["/api/supply-chain"]
    end

    style AC fill:#f1f8ff,stroke:#0366d6,stroke-width:2px
    style KG fill:#dcffe4,stroke:#28a745,stroke-width:2px
    

2.2 与 OpenClaw 的对应关系

3 Skill 设计

[
  {
    "id": "ent_001",
    "name": "华为技术有限公司",
    "type": "company",
    "industry": "通信设备",
    "tags": ["5G", "芯片设计", "ICT"],
    "brief": "全球领先的ICT基础设施和智能终端提供商",
    "relevance_score": 0.95
  }
]

mindmap
  root((事件拆解))
    直接影响
      被点名企业
      被管制行业
      政策直接覆盖领域
    供应链
      上游原材料/零部件
      下游终端产品
      断供/涨价传导
    资本关联
      投资方/被投资方
      控股/参股关系
      母子公司影响
    竞争替代
      同行业竞争者
      替代品/技术提供方
      对手困境→自身机会
    地域/政策
      受影响地域范围
      关联企业
      跨国地缘风险
    宏观传导
      行业整体景气度
      上下游行业间接影响
      消费者/终端市场
        

flowchart LR
    S1["Step 1\n锚定直接影响"] --> S2["Step 2\n一阶传导\n（1 跳）"]
    S2 --> S3["Step 3\n二阶传导\n（2-3 跳）"]
    S3 --> S4["Step 4\n反向受益分析"]
    S4 --> S5["Step 5\n综合评估"]

    style S1 fill:#ffeef0,stroke:#d73a49,stroke-width:2px
    style S2 fill:#fff8f0,stroke:#e36209,stroke-width:2px
    style S3 fill:#f5f0ff,stroke:#6f42c1,stroke-width:2px
    style S4 fill:#dcffe4,stroke:#28a745,stroke-width:2px
    style S5 fill:#f1f8ff,stroke:#0366d6,stroke-width:2px
        

4 Agent 循环框架详细设计

Agent 循环框架是本系统的核心引擎，负责协调事件拆解、图谱检索、影响推理三个阶段的执行，管理状态流转和资源预算。

4.1 状态机设计

Agent 主循环采用有限状态机（FSM）?有限状态机 (FSM)一种经典的程序控制模型。把整个分析流程分成若干"状态"（如拆解中、检索中、推理中），每个状态有明确的输入输出和转移条件。好处是：

• 流程可控，不会跑偏
• 每个阶段职责清晰
• 异常时可以回退到上一状态重试
• 便于追踪当前进度

stateDiagram-v2
    [*] --> INIT: 用户输入事件
    INIT --> DECOMPOSE: 解析事件文本
    DECOMPOSE --> PLAN: 生成查询计划
    PLAN --> RETRIEVE: 执行查询
    RETRIEVE --> EVALUATE: 返回结果
    EVALUATE --> PLAN: 信息不足\n调整计划
    EVALUATE --> SUMMARIZE: 累积Token超阈值
    SUMMARIZE --> PLAN: 压缩完成\n继续检索
    EVALUATE --> REASON: 信息充分 OR\n达到最大轮次
    REASON --> OUTPUT: 推理完成
    OUTPUT --> [*]: 输出报告

    note right of EVALUATE
      核心决策节点
      判断检索是否充分
    end note

    note right of SUMMARIZE
      渐进式摘要
      压缩已有数据
    end note
    

状态定义

4.2 检索循环控制

检索阶段是 Agent 循环中最复杂的部分，采用 Plan → Retrieve → Evaluate?Plan-Retrieve-Evaluate 循环模拟人类分析师的工作方式：

• Plan：想清楚要查什么（"我先查华为的供应商"）
• Retrieve：执行查询，拿到数据
• Evaluate：看看数据够不够（"供应链查到了，但竞争对手还没查"）→ 不够就回到 Plan 补充

flowchart TB
    P["📋 PLAN\n生成/调整查询计划"] --> R["🔍 RETRIEVE\n批量执行查询"]
    R --> E{"🧐 EVALUATE\n信息充分？"}
    E -->|"❌ 信息不足\n发现新线索"| ADJ["调整查询计划\n补充新维度"]
    ADJ --> P
    E -->|"⚠️ Token 超阈值"| S["📝 SUMMARIZE\n渐进式摘要压缩"]
    S --> P
    E -->|"✅ 信息充分"| DONE["进入 REASON"]
    E -->|"🔢 达到最大轮次"| DONE

    style P fill:#f1f8ff,stroke:#0366d6,stroke-width:2px
    style R fill:#fff8f0,stroke:#e36209,stroke-width:2px
    style E fill:#f5f0ff,stroke:#6f42c1,stroke-width:2px
    style S fill:#e6fcfc,stroke:#0ca4a5,stroke-width:2px
    style DONE fill:#dcffe4,stroke:#28a745,stroke-width:2px
    

查询计划生成策略

每轮查询数量控制

检索终止条件

EVALUATE 阶段基于以下条件判断是否终止检索循环：

4.3 信息充分性评估模型?为什么需要评估模型？Agent 不能无限制地查下去（耗时、耗 token），也不能查太少就下结论。这个模型就是帮 Agent 判断"我查的够不够了"的决策机制，从四个角度打分，≥75 分就认为信息够了，可以开始推理。

EVALUATE 是循环的核心决策节点，采用多维评分机制：

flowchart LR
    subgraph 评估维度
        direction TB
        C1["维度覆盖率\n各分析维度是否有数据支撑"]
        C2["实体饱和度\n核心实体的关系是否已充分探查"]
        C3["链路完整度\n影响传导链是否有断裂"]
        C4["新发现率\n本轮是否有新的重要发现"]
    end

    C1 --> SC["综合评分\n0-100"]
    C2 --> SC
    C3 --> SC
    C4 --> SC

    SC -->|"≥ 75 分"| GO["✅ 信息充分\n进入推理"]
    SC -->|"< 75 分"| CONT["🔄 继续检索\n补充信息"]

    style SC fill:#f5f0ff,stroke:#6f42c1,stroke-width:2px
    style GO fill:#dcffe4,stroke:#28a745,stroke-width:2px
    style CONT fill:#fff8f0,stroke:#e36209,stroke-width:2px
    

4.4 渐进式摘要机制?渐进式摘要LLM 有上下文窗口限制（如 200K token），查询数据不断累积会撑满窗口。渐进式摘要的做法是：当数据量超过阈值时，把已有的原始数据压缩成精华摘要，释放空间继续查。类比：笔记本快写满了，先把前面的内容整理成提纲，腾出空白页继续记。

当累积的图谱数据超过 Token 阈值时，启动摘要压缩以释放上下文空间：

flowchart TB
    subgraph 摘要流程
        direction TB
        A["📊 累积数据 > 50K tokens"] --> B["分类归档\n按维度整理已有数据"]
        B --> C["提取关键信息\n实体、关系、影响判断"]
        C --> D["压缩表示\n结构化摘要 ~15K tokens"]
        D --> E["替换原始数据\n释放 ~35K 空间"]
    end

    subgraph 保留内容
        direction TB
        K1["✅ 核心实体 ID 和关键属性"]
        K2["✅ 已确认的关系和传导路径"]
        K3["✅ 各维度的中间结论"]
        K4["✅ 尚未验证的假设和线索"]
    end

    subgraph 可压缩内容
        direction TB
        D1["📦 原始查询的完整 JSON 响应"]
        D2["📦 重复/冗余的实体信息"]
        D3["📦 低相关性的查询结果"]
    end

    style A fill:#fff8f0,stroke:#e36209
    style D fill:#dcffe4,stroke:#28a745
    

摘要触发条件与压缩比

4.5 Agent 内部数据结构

Agent 在循环过程中维护以下核心数据结构：

{
  "session": {
    "event_id": "evt_20260411_001",
    "event_text": "美国对中国芯片出口管制进一步收紧",
    "state": "EVALUATE",
    "current_round": 2,
    "max_rounds": 5
  },
  "decomposition": {
    "dimensions": [
      {
        "name": "直接影响",
        "priority": 1,
        "hypothesis": "受管制的芯片设计/制造企业将直接受损",
        "status": "covered",
        "coverage_score": 85
      },
      {
        "name": "供应链传导",
        "priority": 1,
        "hypothesis": "上游设备/材料供应商和下游客户受间接影响",
        "status": "partial",
        "coverage_score": 60
      }
    ]
  },
  "evidence_pool": {
    "entities_discovered": 23,
    "entities_explored": 15,
    "relations_found": 47,
    "impact_chains": [
      {
        "path": ["芯片管制", "华为海思", "台积电"],
        "direction": "negative",
        "confidence": "high",
        "evidence_refs": ["query_001", "query_003"]
      }
    ]
  },
  "budget": {
    "total_tokens": 200000,
    "used_tokens": 65000,
    "data_tokens": 48000,
    "summarized": false,
    "remaining_for_reasoning": 30000
  }
}

4.6 异常处理与容错

5 Agent System Prompt

Agent 的 System Prompt 将三个 Skill 串联为完整的工作流程：

6 知识图谱接口需求规约

以下是 Agent 团队对知识图谱团队的接口需求规约。Agent 侧通过 kgquery CLI 封装这些 API 调用，图谱团队需按此规约提供 REST API 服务。

6.1 实体（Node）类型定义

图谱中需支持以下实体类型，每种类型有必选属性和可选属性：

6.2 关系（Edge）类型定义

图谱中需支持以下关系类型。每条边需包含 source_id、target_id、type，以及关系特有属性：

6.3 API Endpoints 需求

图谱服务需提供以下 6 个 REST API：

① POST /api/search — 实体模糊搜索

// 请求
{
  "query": "华为",
  "type": "company",          // 可选，过滤实体类型
  "industry": "半导体",       // 可选，过滤行业
  "limit": 10,                // 默认 10，最大 50
  "offset": 0                 // 分页偏移
}

// 响应
{
  "status": "ok",
  "count": 3,                 // 总匹配数
  "truncated": false,
  "data": [
    {
      "id": "ent_001",
      "name": "华为技术有限公司",
      "type": "company",
      "industry": "通信设备",
      "tags": ["5G", "芯片设计"],
      "brief": "全球领先的ICT基础设施提供商",
      "relevance_score": 0.95
    }
  ],
  "summary": "找到 3 家与'华为'相关的公司，主要分布在通信设备和半导体行业"
}

② GET /api/entity/{id} — 实体详情

// 请求参数
// fields: 逗号分隔，控制返回字段（默认 basic,business,tags）
// 可选值: basic, business, tags, finance, shareholders, products

// 响应
{
  "status": "ok",
  "data": {
    "id": "ent_001",
    "name": "华为技术有限公司",
    "type": "company",
    "stock_code": null,
    "industry": "通信设备",
    "sub_industry": "通信系统设备",
    "market": null,
    "market_cap": null,
    "revenue": "7042亿元(2023)",
    "main_products": ["5G基站", "智能终端", "云计算"],
    "region": "广东深圳",
    "tags": ["5G", "芯片设计", "ICT", "鸿蒙"],
    "brief": "全球领先的ICT基础设施和智能终端提供商"
  }
}

③ POST /api/relations — 关系查询

// 请求
{
  "entity_id": "ent_001",
  "type": ["supplier", "customer"],  // 可选，关系类型过滤（数组）
  "direction": "both",               // in / out / both
  "depth": 1,                        // 默认 1，最大 3
  "limit": 20                        // 默认 20，最大 100
}

// 响应
{
  "status": "ok",
  "count": 15,
  "truncated": false,
  "data": [
    {
      "relation_type": "supplier",
      "direction": "in",
      "source": {"id": "ent_042", "name": "台积电", "type": "company", "industry": "半导体制造"},
      "target": {"id": "ent_001", "name": "华为技术有限公司"},
      "properties": {
        "product_category": "芯片代工",
        "dependency_level": "高",
        "revenue_share": 0.15
      }
    }
  ],
  "summary": "华为共有 15 条供应商/客户关系，上游以半导体(5家)和光电(3家)为主"
}

④ POST /api/path — 最短路径查询

// 请求
{
  "source_id": "ent_001",
  "target_id": "ent_099",
  "max_depth": 4,                    // 默认 4，最大 6
  "relation_types": ["supplier", "customer", "investment"]  // 可选，限定边类型
}

// 响应
{
  "status": "ok",
  "paths_found": 2,
  "data": [
    {
      "length": 3,
      "nodes": ["ent_001", "ent_042", "ent_077", "ent_099"],
      "edges": [
        {"type": "customer", "from": "ent_001", "to": "ent_042"},
        {"type": "supplier", "from": "ent_042", "to": "ent_077"},
        {"type": "investment", "from": "ent_077", "to": "ent_099"}
      ],
      "node_details": {
        "ent_001": {"name": "华为", "industry": "通信设备"},
        "ent_042": {"name": "台积电", "industry": "半导体制造"},
        "ent_077": {"name": "ASML", "industry": "半导体设备"},
        "ent_099": {"name": "蔡司半导体", "industry": "光学设备"}
      }
    }
  ],
  "summary": "找到 2 条从华为到蔡司半导体的路径，最短路径经过台积电和ASML，长度为3跳"
}

⑤ GET /api/industry/{name} — 行业查询

// 请求参数
// sub_industry: 二级行业过滤
// sort_by: 排序字段（market_cap / revenue）
// limit: 默认 20

// 响应
{
  "status": "ok",
  "industry": {"name": "半导体", "level": "一级", "company_count": 156},
  "sub_industries": [
    {"name": "芯片设计", "company_count": 67},
    {"name": "半导体制造", "company_count": 23},
    {"name": "封装测试", "company_count": 41},
    {"name": "半导体设备", "company_count": 25}
  ],
  "top_companies": [
    {"id": "ent_201", "name": "中芯国际", "sub_industry": "半导体制造", "market_cap": "3200亿"},
    {"id": "ent_202", "name": "海思半导体", "sub_industry": "芯片设计", "market_cap": null}
  ],
  "summary": "半导体行业共 156 家公司，分布在芯片设计(67)、封测(41)、设备(25)、制造(23)四个子行业"
}

⑥ POST /api/supply-chain — 供应链穿透查询

// 请求
{
  "entity_id": "ent_001",
  "direction": "upstream",    // upstream(上游供应商) / downstream(下游客户)
  "depth": 2,                 // 默认 2，最大 3
  "limit": 30
}

// 响应
{
  "status": "ok",
  "root": {"id": "ent_001", "name": "华为"},
  "direction": "upstream",
  "depth": 2,
  "count": 18,
  "truncated": false,
  "data": {
    "depth_1": [
      {
        "id": "ent_042", "name": "台积电",
        "relation": "supplier",
        "product_category": "芯片代工",
        "dependency_level": "高"
      }
    ],
    "depth_2": [
      {
        "id": "ent_077", "name": "ASML",
        "relation": "supplier",
        "via": "ent_042",
        "product_category": "光刻机",
        "dependency_level": "高"
      }
    ]
  },
  "summary": "华为上游供应链 2 跳内共 18 家企业，一级供应商以芯片代工(3家)和电子元器件(5家)为主"
}

6.4 通用接口要求

6.5 数据质量要求

7 kgquery CLI 工具规约

7.1 技术选型

7.2 完整命令参考

7.3 统一输出结构

{
  "status": "ok",
  "command": "relations",
  "params": {"entity_id": "ent_001", "type": "供应商", "depth": 1},
  "count": 5,
  "truncated": false,
  "data": [ "..." ],
  "summary": "华为的供应商共 5 家，主要集中在半导体和光电领域"
}

7.4 错误处理

{
  "status": "error",
  "error_code": "ENTITY_NOT_FOUND",
  "message": "未找到匹配 '华为芯片' 的实体，建议尝试: '华为' 或 '海思半导体'",
  "suggestions": ["华为技术有限公司", "海思半导体有限公司"]
}

Agent 友好的错误信息，附带建议，减少 Agent 的重试盲目性。

8 运行时流程示例

Phase 1: 事件拆解输出

flowchart TB
    E["🌐 美国加强对华芯片出口管制"] --> D1
    E --> D2
    E --> D3

    subgraph D1["直接影响"]
        direction TB
        D1a["🔍 search '芯片设计'\n--industry 半导体"]
        D1b["🔍 search '芯片制造'\n--industry 半导体"]
    end

    subgraph D2["供应链传导"]
        direction TB
        D2a["🔍 supply-chain {华为ID}\n--direction upstream"]
        D2b["🔍 supply-chain {中芯ID}\n--direction upstream"]
    end

    subgraph D3["竞争替代"]
        direction TB
        D3a["🔍 search '国产替代 EDA'\n--industry 半导体"]
        D3b["🔍 search 'RISC-V'\n--limit 10"]
    end

    style E fill:#f5f0ff,stroke:#6f42c1,stroke-width:2px
    style D1 fill:#ffeef0,stroke:#d73a49
    style D2 fill:#fff8f0,stroke:#e36209
    style D3 fill:#dcffe4,stroke:#28a745
    

Phase 2: 迭代检索过程

Phase 3: 影响分析结果

flowchart TB
    Event["🌐 芯片出口管制收紧"]

    Event -->|"直接受管制"| HW["华为海思\n🔴 高度负面"]
    Event -->|"直接受管制"| SMIC["中芯国际\n🔴 高度负面"]

    HW -->|"订单取消"| TSMC["台积电\n🟠 中度负面"]
    SMIC -->|"设备受限"| ASML["ASML\n🟠 中度负面"]

    Event -->|"国产替代需求↑"| ZW["中微公司\n🟢 中度正面"]
    Event -->|"国产EDA需求↑"| HD["华大九天\n🟢 中度正面"]

    style Event fill:#f5f0ff,stroke:#6f42c1,stroke-width:2px
    style HW fill:#ffeef0,stroke:#d73a49,stroke-width:2px
    style SMIC fill:#ffeef0,stroke:#d73a49,stroke-width:2px
    style TSMC fill:#fff8f0,stroke:#e36209,stroke-width:2px
    style ASML fill:#fff8f0,stroke:#e36209,stroke-width:2px
    style ZW fill:#dcffe4,stroke:#28a745,stroke-width:2px
    style HD fill:#dcffe4,stroke:#28a745,stroke-width:2px
    

影响实体卡片

9 Agent 输出格式规范

Agent 的最终输出采用结构化 JSON 格式，便于下游系统（前端可视化、数据存储、API 对外服务）直接消费。

12.1 顶层输出结构

{
  "meta": {
    "event_id": "evt_20260411_001",
    "event_text": "美国对中国芯片出口管制进一步收紧",
    "analysis_time": "2026-04-11T10:23:00Z",
    "duration_seconds": 45,
    "rounds": 3,
    "data_quality": "normal",
    "model": "claude-opus"
  },
  "summary": "本次管制收紧直接影响华为海思、中芯国际等 6 家企业，通过供应链传导间接影响台积电、ASML 等 4 家上游企业，同时利好中微公司、华大九天等 3 家国产替代企业。",
  "impact_entities": [ "..." ],
  "impact_chains": [ "..." ],
  "dimensions_coverage": { "..." },
  "limitations": [ "..." ]
}

12.2 影响实体（impact_entities）

{
  "entity_id": "ent_001",
  "entity_name": "华为海思",
  "stock_code": null,
  "industry": "芯片设计",
  "impact_direction": "negative",
  "impact_level": "high",
  "confidence": "high",
  "impact_summary": "作为受管制的核心实体，高端芯片设计业务将直接受限",
  "evidence": [
    {
      "type": "direct",
      "description": "管制名单直接覆盖",
      "source_query": "search '华为海思' --type company"
    }
  ],
  "transmission_path": {
    "hops": 0,
    "path_description": "直接影响"
  }
}

字段枚举值

10.3 影响链（impact_chains）

{
  "chain_id": "chain_001",
  "description": "管制 → 华为海思(芯片设计受限) → 台积电(代工订单减少)",
  "direction": "negative",
  "nodes": [
    {"entity_id": "event", "label": "芯片管制收紧"},
    {"entity_id": "ent_001", "label": "华为海思", "impact": "high_negative"},
    {"entity_id": "ent_042", "label": "台积电", "impact": "medium_negative"}
  ],
  "edges": [
    {"from": "event", "to": "ent_001", "relation": "直接管制", "mechanism": "出口管制名单覆盖"},
    {"from": "ent_001", "to": "ent_042", "relation": "customer", "mechanism": "芯片代工订单取消/减少"}
  ],
  "confidence": "high",
  "hops": 1
}

9.4 维度覆盖情况（dimensions_coverage）

{
  "直接影响": {"status": "covered", "entities_found": 6, "score": 90},
  "供应链传导": {"status": "covered", "entities_found": 8, "score": 75},
  "资本关联": {"status": "partial", "entities_found": 2, "score": 50},
  "竞争替代": {"status": "covered", "entities_found": 3, "score": 80},
  "地域政策": {"status": "skipped", "entities_found": 0, "score": 0},
  "宏观传导": {"status": "partial", "entities_found": 1, "score": 30}
}

该字段让下游系统和用户清楚地知道分析覆盖了什么、遗漏了什么，是分析质量透明度的关键。

10 Token 预算管理?什么是 Token 预算？Token 是 LLM 处理文本的基本单位（约等于 0.7 个中文字）。LLM 的上下文窗口有容量上限（如 200K token），所有输入输出必须在这个预算内完成。预算管理就是合理分配这个"空间"给各个阶段，确保不会"写到一半纸用完了"。

12.1 预算分配策略

以 200K 上下文窗口为例：

12.2 渐进式摘要策略

当 Phase 2 累积数据超过 50K token 时，触发中间摘要：

flowchart LR
    A["📊 累积图谱数据\n> 50K tokens"] -->|"LLM 摘要压缩"| B["📝 压缩后关键信息\n~15K tokens"]
    B -->|"继续检索"| C["📊 新数据追加\n到压缩摘要之后"]
    C -->|"是否超阈值?"| A

    style A fill:#fff8f0,stroke:#e36209
    style B fill:#dcffe4,stroke:#28a745
    style C fill:#f1f8ff,stroke:#0366d6
    

10.3 输出控制

• 所有查询默认 --limit 不超过 20
• summary 字段控制在 200 字以内
• 实体详情默认只返回 basic,business,tags，需要时再查 finance,shareholders

11 评测方案

Agent 分析质量的评测是持续迭代优化的基础。我们从三个层面建立评测体系：

13.1 评测指标

13.2 测试集构建

13.3 标注规范

每个事件的 ground truth 标注包含：

{
  "event_id": "test_001",
  "event_text": "欧盟对中国电动车加征反补贴关税",
  "annotator": "标注人姓名",
  "annotated_at": "2026-05-20",
  "affected_entities": [
    {
      "entity_name": "比亚迪",
      "impact_direction": "negative",
      "impact_level": "high",
      "reasoning": "作为对欧出口量最大的中国电动车企，直接受关税影响",
      "dimension": "直接影响"
    },
    {
      "entity_name": "宁德时代",
      "impact_direction": "negative",
      "impact_level": "medium",
      "reasoning": "作为比亚迪电池供应商，间接受订单下降影响",
      "dimension": "供应链传导"
    }
  ],
  "expected_chains": [
    "关税 → 比亚迪(出口受限) → 宁德时代(电池订单减少)",
    "关税 → 中国电动车整体(竞争力下降) → 欧洲本土车企(受益)"
  ],
  "difficulty": "medium"
}

13.4 评测流程

flowchart LR
    A["📝 测试事件输入"] --> B["🤖 Agent 分析"]
    B --> C["📊 输出结果"]
    C --> D["🔄 自动评测\n实体匹配 + 方向/程度对比"]
    C --> E["👤 人工评测\n传导链合理性评分"]
    D --> F["📈 评测报告\n各指标得分 + 错误分析"]
    E --> F

    style D fill:#f1f8ff,stroke:#0366d6,stroke-width:2px
    style E fill:#fff8f0,stroke:#e36209,stroke-width:2px
    style F fill:#dcffe4,stroke:#28a745,stroke-width:2px
    

12 扩展性设计

12.1 新增 Skill（即插即用）

Agent 端只需在 System Prompt 中声明加载新 Skill，无需修改推理框架。

12.2 多 Agent 协作（V2）?多 Agent 协作当事件影响范围很广时（如"全球经济衰退"），单个 Agent 分析所有行业太慢。V2 方案是让多个子 Agent 并行分析不同行业（科技、金融、制造……），最后由主 Agent 汇总。就像一个分析团队分工合作，每人负责一个行业，最后组长写总报告。

flowchart TB
    Main["🧠 主 Agent\n协调者"] --> A1["🖥️ 子 Agent 1\n科技行业影响"]
    Main --> A2["🏦 子 Agent 2\n金融行业影响"]
    Main --> A3["🏭 子 Agent 3\n制造业影响"]

    A1 -->|分析结果| Main
    A2 -->|分析结果| Main
    A3 -->|分析结果| Main

    Main --> R["📄 汇总报告"]

    style Main fill:#f5f0ff,stroke:#6f42c1,stroke-width:2px
    style R fill:#dcffe4,stroke:#28a745,stroke-width:2px
    

各子 Agent 共享同一套 Skills，但分析不同维度；主 Agent 汇总各子 Agent 的分析结果。

13 实施建议

13.1 团队配置

Agent 循环框架的开发涉及多个高耦合模块，需要足够的人力保障并行推进：

13.2 里程碑规划

13.3 里程碑甘特图

gantt
    title Agent 循环框架开发计划
    dateFormat  YYYY-MM-DD
    axisFormat  %m/%d

    section 阶段一：基础框架
    状态机核心开发           :a1, 2026-04-14, 14d
    kgquery CLI 开发         :a2, 2026-04-14, 10d
    接口对齐与联调           :a3, 2026-04-14, 7d
    Skill & Prompt 编写      :a4, 2026-04-28, 10d
    端到端验证               :a5, 2026-05-05, 5d

    section 阶段二：检索与推理优化
    充分性评估模型           :b1, 2026-05-12, 10d
    Token 预算管理           :b2, 2026-05-12, 10d
    Prompt 迭代优化          :b3, 2026-05-26, 10d
    异常处理与容错           :b4, 2026-05-26, 7d
    质量评估基准建立         :b5, 2026-05-19, 14d

    section 阶段三：能力扩展
    news-search Skill        :c1, 2026-06-08, 10d
    financial-data Skill     :c2, 2026-06-08, 10d
    多事件关联分析           :c3, 2026-06-22, 7d
    回归测试 & 压测          :c4, 2026-06-29, 5d

    section 阶段四：产品化对接
    输出接口标准化         :d1, 2026-07-06, 10d
    多 Agent 协作          :d2, 2026-07-06, 14d
    推理日志结构化         :d3, 2026-07-13, 7d
    联调集成测试 & 上线    :d4, 2026-07-27, 5d
    

13.4 风险与依赖