Skill 如何共享 Agent 的上下文（Context）？上下文的数据结构一般如何设计？

面试官：“多个 Skill 之间怎么共享 Agent 的上下文？这个上下文的数据结构你会怎么设计？”

候选人：

“上下文是 Skill 之间无声的默契。设计上下文共享机制时，我最关心的是：怎么让 Skill 既拿到需要的数据，又不会互相踩脚，还能支持断点续执行和跨版本兼容。 我分成机制和结构两层来说。

一、共享机制：基于声明式键映射的全局 TaskContext

每个任务启动时，编排引擎创建一个 TaskContext 对象，这个对象贯穿任务的所有 Skill。上下文不直接传给 Skill，而是 Skill 在元信息里声明“我需要什么”和“我能给什么”，编排引擎负责注入和收集。

• 输入声明：Skill A 的元信息里声明参数 temperature，来源为 context:weather.current_temp。执行前，引擎从上下文里取值注入。

• 输出声明：Skill B 执行完后，引擎根据它的输出元信息，把 temperature: 26 写回 context:weather.current_temp。

• 隔离：Skill 只能读自己声明的键，写自己声明的键。这就在数据层面实现了接口式解耦。

二、数据结构设计：分区命名空间 + 多版本兼容

上下文不是简单的键值堆砌，我把它设计成三层命名空间结构：

TaskContext
├── user_input        (用户原始输入及澄清结果)
├── skill_outputs     (各 Skill 产生的数据)
│   ├── weather_query
│   │   └── current_temp: 26
│   ├── flight_book
│   │   └── booking_id: "FL123"
│   └── ...
├── task_state        (任务状态与断点信息)
│   ├── current_step: "waiting_confirmation"
│   ├── completed_steps: ["weather_query", "flight_search"]
│   └── pending_skill: "hotel_booking"
└── metadata          (任务元信息)
    ├── task_id: "task_abc123"
    ├── user_id: "u_10086"
    ├── locale: "zh-CN"
    └── created_at: "2026-06-23T10:00:00Z"

每层具体设计考虑：

• user_input：保存用户的原始自然语言指令和后续交互中澄清的参数，比如“下周二去深圳”解析后的结构化参数。这样任何 Skill 都能回溯用户的原始意图，而不是只看上游 Skill 转换后的结果。

• skill_outputs：按 Skill 名称划分命名空间，每个 Skill 只在自己的子空间写入。这防止了键冲突，也方便调试——一眼就知道哪个数据是哪个 Skill 产生的。每个值除了数据本身，还可以附带类型信息和生成时间戳，方便校验和排序。

• task_state：记录编排引擎的状态机状态，用于断点恢复。它不是给 Skill 看的，而是给编排引擎自己用的。

• metadata：跨所有 Skill 共享的全局信息，如用户 ID、语言偏好、租户 ID。这些信息由 Agent 核心在任务创建时注入，Skill 可以直接读取但不可修改。

三、值的设计：带元信息的包装

普通字符串或数字太脆弱，我让上下文中的每个值都带一些元信息，以方便调试和智能决策：

{
  "current_temp": {
    "value": 26,
    "type": "number",
    "source": "weather_query_v2.1",
    "produced_at": "2026-06-23T10:00:05Z",
    "confidence": 0.98,
    "ttl_ms": 1800000
  }
}

• source：记录是哪个 Skill 产生的，方便溯源。

• confidence：有些 Skill 可能产出不确定的结果，下游可以据此决定是否采用或重新查询。

• ttl：时效性。比如天气数据 30 分钟后过期，下游若发现已过期，可触发重新获取而非用旧数据。

---