graft

本页关注点

本页讲的是云端 builtin 版的 graft——combo agent 平台 Agent 通过 unified_search 在云端进程内跨 session 嫁接。

在 本地 IDE（Cursor / Claude Code / Codex）里通过 HTTPS 访问云端 session 的版本看 skills/coding-agents/graft-comboagent
机制与底层设计（存储模型、权限隔离、context 注入策略等）看核心概念 · Graft 跨会话嫁接

为什么需要 graft

当一个复杂项目涉及多个独立分析（例如 ASPICE 案例中 v1.14 基线追溯、v1.17 基线追溯、变更分析、覆盖审计），把它们塞到同一个 Session会带来：

上下文爆炸，压缩时细节丢失
Agent 配置/技能集相互干扰
一处错误影响全盘
难以分工、难以审阅

graft 解决的正是这个问题：让独立 Session 各自完成本职分析，需要协作时再按需"嫁接"引用对方的结构化产出。

Graft = 把某个 Session 的执行结果"嫁接"到当前 Session 的 context，用完即走，不污染宿主。

核心操作：三个 action

graft 技能完全对齐 kb_ids/doc_ids 的已有检索模式，统一通过 unified_search 工具调用，暴露三个 action：

① `list_sessions` — 发现

unified_search(action="list_sessions", query="冷却")

返回同租户下可见的 Session 列表（自己的 + 被共享的），支持名称关键词过滤。输出：

字段	说明
`session_id`	Session 的唯一 ID
`name`	人读友好的 Session 名称
`agent_name`	承载该 Session 的 Agent
`updated_at`	最近更新时间
`visibility`	`private` / `shared`

② `get_digest` — 看全貌

unified_search(action="get_digest", session_id="冷却系统分析")

返回该 Session 的完整执行摘要表：每一轮做了什么、产出了什么、状态如何、有哪些产物。相当于"进入别人 Session 前的目录索引"。

session_id 支持 ID 和名称（同 _resolve_kb_ids 模式），名称会自动解析。

③ `get_round` — 取数据

unified_search(action="get_round", round_id=5, session_id="冷却系统分析")

把指定 Session 指定轮次的精确输入输出嫁接到当前 context。Agent 据此可以：

引用对方的结论做对比分析
继承对方的中间数据继续下游处理
交叉验证多视角结论

标准使用流程

Rendering diagram…

如果用户已经明确说了 Session 名称，可以跳过 Step 0 直接进 Step 1。

真实使用案例

案例 1：ASPICE 版本变更影响分析

背景：v1.14 基线追溯与 v1.17 基线追溯已经在两个独立 Session 完成，现在要做差异分析。

/graft
场景二（变更分析 Session）引用两个基线 Session：

  unified_search(action="get_digest", session_id="v1.14-基线追溯")
  unified_search(action="get_digest", session_id="v1.17-基线追溯")
  → 获取两个基线的节点/追溯链全貌

  unified_search(action="get_round", round_id=<追溯重建轮>, session_id="v1.14-基线追溯")
  unified_search(action="get_round", round_id=<追溯重建轮>, session_id="v1.17-基线追溯")
  → 取精确的 303 节点 + 396 追溯链

  → 产出 178 条变更 + 313 个受影响节点

节省：两个基线文档不再需要重读，Agent 直接用对方已经结构化的 JSON 结果。参阅 ASPICE 案例场景二。

案例 2：测试覆盖审计交叉验证

背景：场景一已完成需求-测试追溯审计，现在从"测试视角"再审一次，并与场景一结果比对。

/graft
场景四（覆盖审计 Session）引用：

  场景一 → 拿 303 节点的追溯关系
  场景三 → 拿新生成的 CAPL 用例

  → 产出"34/14/79"三向一致性分布
  → 差异项自动标为"待复核"

价值：避免单一视角误判，输出可信度远高于单 Session 分析。见 ASPICE 案例场景四。

案例 3：专利撰写复用前序新颖性检索

背景：3 天前完成了一个专利方向的新颖性检索，现在要撰写说明书。

/graft 引用上周完成的"电机控制专利查新"

  → Agent 拉取对方 Session 的检索结果（13 个数据源的 prior art 列表）
  → 直接进入权利要求书撰写，不重复查新

设计原则

原则	说明
用户显式激活	必须通过 `/graft` 命令或明确自然语言触发，Agent 不能在无许可下自行跨 Session
同租户内隔离	跨租户严格禁止，租户间数据零泄漏
按需引用	不把整个 Session 拷贝进来，只嫁接需要的轮次/数据
全量审计日志	每次 graft 操作都记录到 ledger：谁、在哪个 Session、引用了哪个 Session 的哪一轮
权限继承	只能引用"你本来就有权限看"的 Session（自己的 + 被 share 的）

常见问题

Q: graft 会把对方 Session 的全部历史拉进来吗？

不会。get_round 只嫁接指定轮次的结构化数据，配合 get_digest 的目录导航，精准取用、控制 token 膨胀。

Q: 如果对方 Session 还在运行能 graft 吗？

可以。get_digest 返回的是快照，不会阻塞对方执行。但如果你要引用的轮次还没产生，会明确报错。

Q: graft 和 Memory（长期记忆）有什么区别？

维度	graft	Memory（LTM）
粒度	Session 级（多轮）	知识单元级（单条）
触发	用户显式	Agent 按需自动检索
范围	同租户全部 Session	写入时指定 scope
用途	复用某次完整分析	长期知识沉淀