Appearance
Coding Agent 如何跨 Context 持续推进：Skills、Incremental Progress 与 Handoff
前置：跨进程继续代码任务：Sandbox Session、Snapshot 与 Resume
核心问题：长代码任务跨 Context/Agent 时，Skill 应何时加载、Progress 应记录什么，Handoff 怎样避免把整段历史一起搬过去？
只有处理 PDF 时加载 pdf skill；第三方 skill 未验证签名/来源前不能自动执行其 shell hooks。每完成一个模块就 commit/stage diff 或更新 progress，测试失败原因也记录，下一 session 无需从头猜。
Mental Model
Workspace 是模型 Context 之外的持久工作环境；Tool 对文件、shell、Git、test 的真实操作都在这里留下可重新读取的事实和 artifact。
Skills / Progressive Capability Loading
Skills 先索引 capability，任务相关时再 materialize instructions/assets，减少 context 和能力暴露；skill 来源本身要有信任策略。
Skill 是可复用的说明、脚本或能力包，应按任务需要渐进发现/加载，避免全部占 context。Skill 本身属于供应链输入，需要来源/version/trust。
Coding-Agent Incremental Progress
长 coding task 每次只完成可验证增量，并写 progress/decision/artifact，下一 context 从 workspace 重新 grounding，而不是依赖隐式聊天记忆。
避免一次积累大量未验证变更。
Structured Handoff Across Contexts
Handoff 的目标不是把旧 transcript 全部复制给下一个 Context，而是交付一份足以继续工作的结构化状态。
例如 Coding Run 可以传：
text
objective / constraints
files inspected
accepted/rejected hypotheses
patches already applied
open failures
test evidence
artifact/workspace refs
next recommended step这样下一次 Context Reset 后，新 Agent 不需要重新阅读 200 轮聊天才能知道做到哪里。
真正 durable 的内容应放在 State/Workspace/Artifact 中；handoff 只是重新组装这些事实的工作摘要，不能成为唯一事实来源。
Progressive Loading 怎么减少 Context 噪声
假设 Coding Agent 有 80 个 Skills：Python、SQL、Kubernetes、Terraform、PDF、frontend testing……把每个 Skill 的完整说明都放进 system context 会浪费大量 token，也会增加错误选择概率。
更合理的是分两层：
text
初始 Context：skill name + 一句话能力 + 触发条件
↓ 模型/策略判断需要
按需加载：完整 skill instructions / examples / constraints当 Run 发生 context reset 或 handoff 时，不应该把整个旧对话复制过去。Structured Handoff 可以只传：当前目标、已验证事实、已修改 artifact、未解决问题、必须保留的约束以及下一执行入口。这样新 context 获得的是“继续任务所需状态”，不是上一位 Agent 的全部聊天记忆。
自测
- 几十个 Skill 一次全塞进 Context 会造成什么成本？Progressive loading 应按什么信号加载当前需要的 Skill？
- Handoff 给另一个 Agent 时，哪些 progress/artifact 必须显式传递，哪些旧上下文反而应该隔离？