企业官网建设流程全解析

• 人工智能
• AI Agent
• 代码智能体
• Agent 编排
• CLI
• AI 应用

本文基于仓库 docs/dev/FRONTIER-TECHNIQUES.md 整理。该文档是一份标注为 "Research / Pre-RFC"（研究 / RFC 预稿）的前沿技术调研，发布于 2026-03-25，围绕 GSD-2 的多层事件驱动 Agent 平台，系统评估了六项可直接映射到现有架构的前沿 AI Agent 技术。本文在完整继承原文档骨架的基础上，结合当前仓库源码（尤其是 compaction 与 agent 循环的实现）对每一项技术的落点做了交叉验证。读完本文，你将理解这些技术分别解决什么问题、GSD-2 为什么天然具备它们的集成点、以及按什么顺序落地收益最大。

文档定位：一份面向架构的 Pre-RFC 调研

GSD-2 是一个多层、事件驱动的 Agent 平台，其可扩展原语包括：技能系统（skill system）、基于文件的记忆（file-based memory）、会话分支（session branching）、上下文压缩（compaction），以及 16+ 个扩展生命周期钩子（extension lifecycle hooks）。原文档认为，这些既有原语恰好构成了六项前沿技术的自然集成点，能够让 GSD 的运行方式发生质变。

六项技术被分为三个类别：

需要强调的是：这些技术多数处于"研究建议"层面，尚未全部落地；文档中引用的外部论文与行业资料（如 SkillRL、LLMCompiler、Speculative Tool Calls 等）属于背景依据，本文不展开外部链接，读者如需深入研究可自行检索相应关键词。源码中已确认的事实（如 chars/4 估算逻辑、压缩参数默认值、fork()等原语）将标注对应仓库路径。

1. 技能库进化（Skill Library Evolution）——优先级 #1

• 类别：自我进化
• 影响：巨大（Massive）｜工作量：中等｜优先级：第 1

核心思想

文档参考了 SkillRL（ICLR 2026）的思路，主张把 GSD 的技能系统从"静态指令文件"改造成"自我进化的知识库"：技能不再是一次写死、之后全靠人工维护，而是基于每次执行结果持续演化。SkillRL 的研究结论（文档引用）表明，具备学习型技能库的 Agent 在任务基准上相较基线有显著提升（原文引用 15.3%+），且相比原始轨迹存储可实现 10-20% 的 token 压缩——这些数字属于外部研究引用，本文仅转述，不作项目事实。

工作闭环

┌─────────────────────────────────────────────────────────┐ │ EXECUTION LOOP │ │ │ │ 1. Skill invoked → agent executes task │ │ 2. Outcome captured (success/failure + trajectory) │ │ 3. Trajectory distilled: │ │ ├─ Success → strategic pattern extracted │ │ └─ Failure → anti-pattern + lesson recorded │ │ 4. Skill file updated with versioned improvement │ │ 5. Next invocation benefits from accumulated learnings │ │ │ └─────────────────────────────────────────────────────────┘

学习到的知识分为两类：

为什么适合 GSD-2

文档指出 GSD 已经具备闭环所需的全部原语：

• 技能文件（~/.claude/skills/、.claude/skills/）——存储层已存在；
• 扩展钩子（turn_end、agent_end）——结果捕获点已存在（当前仓库扩展事件体系中确实定义了这些会话事件，见 packages/pi-coding-agent/src/core/extensions/types.ts 及 hooks-runner.ts）；
• 记忆系统（MEMORY.md + 独立文件）——持久化已存在；
• /improve-skill与/heal-skill命令——这一循环的人工版本已存在。

缺口在于自动化：把执行结果自动回写到技能文件，无需人工干预。

架构设计

User invokes skill │ ▼ ┌──────────────┐ ┌──────────────────┐ │ AgentSession │────▶│ Skill Executor │ │ (turn_end) │ │ (tracks outcome) │ └──────────────┘ └────────┬─────────┘ │ ┌─────────▼──────────┐ │ Outcome Classifier │ │ (success/failure/ │ │ partial) │ └─────────┬──────────┘ │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ ┌────────────┐ ┌──────────────┐ ┌───────────┐ │ Success │ │ Failure │ │ Partial │ │ Distiller │ │ Distiller │ │ Analyzer │ └─────┬──────┘ └──────┬───────┘ └─────┬─────┘ │ │ │ ▼ ▼ ▼ ┌─────────────────────────────────────────────┐ │ Skill File Updater │ │ • Appends learned pattern to skill │ │ • Versions the update │ │ • Preserves original skill intent │ └─────────────────────────────────────────────┘

集成点对照

开放问题

• 漂移防护：如何防止积累的学习内容淹没原始技能意图？
• 冲突解决：一个会话学到的教训与另一会话相矛盾时怎么办？
• 质量门：更新写入前是否需要一次校验 pass？

2. 基于 DAG 的并行工具执行（DAG-Based Parallel Tool Execution）——优先级 #2

• 类别：性能
• 影响：高｜工作量：中等｜优先级：第 2

核心思想

文档借鉴 LLM Compiler 模式（ICML 2024）：把多工具工作流当成一次编译器优化 pass。当模型在单次响应中返回多个工具调用时，系统不再顺序执行，而是：

1. 分析工具调用之间的依赖关系；
2. 构造有向无环图（DAG）；
3. 并行执行相互独立的工具；
4. 只在存在真实数据依赖时阻塞。

现状 vs 目标

当前 GSD 行为（顺序）：

Read(auth.ts) ─── 150ms ───▶ result │ Read(types.ts) ─── 120ms ──▶ result │ Grep("login") ─── 80ms ────▶ result │ Read(test.ts) ─── 130ms ───▶ result │ Total: ~480ms sequential

采用 DAG 执行后（并行）：

Read(auth.ts) ─── 150ms ──▶ result ─┐ Read(types.ts) ─── 120ms ──▶ result ─┤ Grep("login") ─── 80ms ───▶ result ─┤── all complete at 150ms Read(test.ts) ─── 130ms ──▶ result ─┘ │ Total: ~150ms (max of parallel set)

依赖分析规则

为什么适合 GSD-2

模型在单次响应中已经会发出多个tool_use块，但当前执行路径在 agent-loop.ts 中按顺序处理。文档估算：一个典型编码轮次包含 3-5 个工具调用，其中约 60% 可并行化（读、grep、glob），每轮延迟可下降 40-60%；一个 50 轮会话可省下数分钟。此处的"40-60%"是文档的估算值，属于研究性推测，未在仓库中有基准测试佐证。

集成点对照

架构设计

Model response with N tool_use blocks │ ▼ ┌──────────────────────────────┐ │ Dependency Analyzer │ │ • Parse tool calls │ │ • Identify file overlaps │ │ • Identify data dependencies │ │ • Classify: pure vs impure │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ DAG Constructor │ │ • Nodes = tool calls │ │ • Edges = dependencies │ │ • Topological sort │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ Parallel Executor │ │ • Execute roots immediately │ │ • On completion, unlock │ │ dependent nodes │ │ • Collect all results │ │ • Return in original order │ └──────────────────────────────┘

开放问题

• Bash 副作用：不实际执行，如何判断两条 Bash 命令是否冲突？
• 扩展钩子顺序：tool_start/tool_end事件按执行顺序还是原始顺序触发？
• 错误传播：并行的某个工具失败时，依赖它的工具是被取消还是收到错误？

3. 推测性工具执行（Speculative Tool Execution）——优先级 #3

• 类别：性能
• 影响：高｜工作量：低-中等｜优先级：第 3

核心思想

基于 Speculative Tool Calls 相关研究（文档引用），该技术预测模型接下来会请求哪些工具，并在模型响应之前就预先执行。预测正确时，首个工具调用的往返延迟被完全消除；预测错误时，代价仅是已消耗的计算（且结果被丢弃）。

工作原理

┌─────────────────────────────────────────────────────────────┐ │ User: "fix the bug in auth.ts" │ │ │ │ BEFORE model responds: │ │ Speculator predicts: │ │ ├─ Read("auth.ts") → pre-executed ✓ │ │ ├─ Grep("error|bug", "auth") → pre-executed ✓ │ │ ├─ LSP diagnostics(auth.ts) → pre-executed ✓ │ │ └─ Read("auth.test.ts") → pre-executed ✓ │ │ │ │ Model responds with tool calls: │ │ ├─ Read("auth.ts") → CACHE HIT (0ms) │ │ ├─ Read("auth.test.ts") → CACHE HIT (0ms) │ │ └─ Grep("login", "src/") → cache miss (execute) │ │ │ │ Hit rate: 2/3 = 67% │ │ Latency saved: ~300ms on this turn │ └─────────────────────────────────────────────────────────────┘

预测策略（从简到繁）

（命中率为文档研究的预期区间，属待验证数据。）

为什么适合 GSD-2

GSD 的最大延迟瓶颈是往返链路：用户提示 → 模型思考 → 模型请求工具 → 工具执行 → 结果回传 → 模型再思考。推测执行直击最高延迟环节。文档认为现有架构让这一功能易于添加：

• AgentSession.prompt()在发给模型之前已经处理用户输入（对应 agent-session.ts 的会话处理链路）；
• 工具结果已缓存在消息数组中；
• 扩展系统可拦截输入并触发预取。

集成点对照

架构设计

User input arrives │ ├──────────────────────────────────────┐ │ │ ▼ ▼ ┌───────────────┐ ┌──────────────────┐ │ Send to LLM │ │ Speculator │ │ (normal path) │ │ • Extract paths │ │ │ │ • Predict tools │ │ ... waiting │ │ • Pre-execute │ │ for response │ │ • Cache results │ │ │ └──────────────────┘ │ │ │ │ │◀─── model returns ──────────│ │ │ tool_use blocks │ └───────┬───────┘ │ │ │ ▼ │ ┌───────────────┐ │ │ Tool Executor │◀──── check cache ───────────┘ │ • Cache hit? │ │ → return │ │ • Cache miss? │ │ → execute │ └───────────────┘

成本分析

开放问题

• 缓存 TTL：推测结果有效期多长？推测与模型请求之间文件内容可能已变化。
• 副作用：是否只有纯工具（Read、Grep、Glob、LSP）才允许被推测？
• 资源上限：每轮推测执行次数是否需要封顶，以避免 I/O 风暴？

4. 语义上下文压缩（Semantic Context Compression）——优先级 #4

• 类别：智能
• 影响：高｜工作量：高｜优先级：第 4

这是六项技术中与当前仓库源码关联最紧密的一项，文档对 GSD 现状的批评可以直接在源码中验证。

当前 GSD 压缩的弱点（文档指出的三点）

Messages: [M1, M2, M3, M4, M5, M6, M7, M8, M9, M10] ▲ Token budget exceeded │ recent │ Current approach: ┌─────────────────────────┬─────────────────────────┐ │ M1-M6: LLM-summarized │ M7-M10: kept verbatim │ │ into single blob │ (last ~20k tokens) │ │ │ │ │ ⚠ All detail lost │ ✓ Full fidelity │ │ ⚠ No selective recall │ │ │ ⚠ char/4 overestimates │ │ └─────────────────────────┴─────────────────────────┘

源码验证（当前仓库）：char/4 估算逻辑确实存在于 packages/pi-coding-agent/src/core/compaction/compaction.ts 的estimateTokens()（约 L225-L283），对 text 块执行Math.ceil(chars / 4)，且注释明确写着 "This is conservative (overestimates tokens)"——与文档描述一致。截断点查找在findCutPoint()（约 L376-L438）：从最新消息反向累加估算 token，达到keepRecentTokens即切，且只允许在 user/assistant/custom/bashExecution 等消息上切、绝不切在 toolResult 上。压缩阈值判定在shouldCompact()（约 L205-L215）：支持contextWindow - reserveTokens的绝对余量判断，也支持thresholdPercent百分比阈值。相关默认常量在 constants.ts：COMPACTION_RESERVE_TOKENS = 16_384、COMPACTION_KEEP_RECENT_TOKENS = 20_000（"最近约 20k tokens 原样保留"的说法与文档图示完全对应）。全有或全无的 LLM 摘要由generateSummary()（约 L599-L708）实现，支持单遍摘要与分块迭代合并，并带有退化摘要防护（isDegenerateSummary，对应 issue #4665）。压缩编排（手动/compact、自动触发、溢出恢复）位于 compaction-orchestrator.ts，且支持session_before_compact扩展钩子。

提议：分层记忆架构（Tiered Memory Architecture）

┌─────────────────────────────────────────────────────────┐ │ HOT TIER │ │ Recent turns (last ~20k tokens) │ │ Full text, full fidelity │ │ Storage: in-context messages │ │ Access: always in prompt │ ├─────────────────────────────────────────────────────────┤ │ WARM TIER │ │ Older turns (beyond context window) │ │ Stored as embeddings + compressed text │ │ Storage: session-local vector index │ │ Access: retrieved when semantically relevant to │ │ current turn │ │ Token cost: only retrieved segments count │ ├─────────────────────────────────────────────────────────┤ │ COLD TIER │ │ Ancient turns / previous sessions │ │ Stored as summaries + metadata │ │ Storage: disk (existing session files) │ │ Access: retrieved only on explicit recall │ │ Token cost: minimal summary headers │ └─────────────────────────────────────────────────────────┘

每轮的检索流程：

New user prompt arrives │ ▼ ┌───────────────────┐ │ Embed the prompt │ (compute embedding of user's question) └────────┬──────────┘ │ ├──── query warm tier ──▶ top-K relevant historical turns │ (cosine similarity > threshold) │ ├──── always include ──▶ hot tier (recent turns, full text) │ ▼ ┌───────────────────┐ │ Compose context │ │ = hot + retrieved │ │ + system prompt │ └───────────────────┘

Token 估算改进

用自适应估算替换 char/4：

文档强调：混合方案——近期消息使用 provider 响应中的实际 token 数、旧消息回退到 char/4——是无需新增依赖即可快速见效的方案。这一点在当前源码中已有雏形：estimateContextTokens()（见 compaction/compaction.ts 约 L168-L196）正是"优先使用最近一条有效 assistant usage，其后消息再逐条估算"的混合思路；calculateContextTokens()只统计input + cacheRead + cacheWrite，排除输出 token。

集成点对照

开放问题

• Embedding 模型：本地（快、私有）还是 API（质量好、有延迟）？
• 索引格式：扁平数组上简单余弦相似度，还是 HNSW 索引？
• 检索预算：每轮给 warm-tier 检索分配多少 token？
• 连贯性：如何防止检索到的历史上下文混淆模型对当前状态的判断？

5. 跨会话学习图（Cross-Session Learning Graph）——优先级 #5

• 类别：自我进化
• 影响：变革性（Transformative）｜工作量：高｜优先级：第 5

核心思想

GSD 当前记忆系统（MEMORY.md + 独立文件）存储的是扁平、基于文件的记忆。学习图把它扩展为结构化知识库，捕获跨所有会话的"代码库—文件—错误—解决方案—模式"之间的关系网络。文档引用了 Agent Memory 研究与 context engineering 文献作为背景。

当前记忆 vs 学习图

图 Schema

┌──────────┐ touches ┌──────────┐ │ Session │────────────────▶│ File │ │ │ │ │ │ • date │ │ • path │ │ • outcome │ │ • type │ │ • tokens │ │ • churn │ └────┬──────┘ └─────┬─────┘ │ │ │ encountered │ involved_in │ │ ▼ ▼ ┌──────────┐ resolved_by ┌──────────┐ │ Error │────────────────▶│ Solution │ │ │ │ │ │ • type │ │ • pattern │ │ • message │ │ • success │ │ • freq │ │ rate │ └──────────┘ └──────────┘ │ │ │ prevented_by │ uses │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Pattern │ │ Tool │ │ │ │ │ │ • type │ │ • name │ │ • desc │ │ • avg │ │ • conf │ │ time │ └──────────┘ └──────────┘

示例查询

集成点对照

存储选型

开放问题

• 隐私：图包含详细的代码库交互历史，静止时是否应加密？
• 可移植性：图随项目走（.claude/目录）还是留在用户本地？
• 垃圾回收：如何剪除过期节点（例如已不存在的文件）？

6. 基于 MCTS 的规划（MCTS-Based Planning）——优先级 #6

• 类别：智能
• 影响：变革性｜工作量：非常高｜优先级：第 6

核心思想

受 ToolTree 与蒙特卡洛树搜索（MCTS）启发，该技术把 GSD 的线性动作选择替换为树形规划器，同时探索多条解决路径：

1. 生成 N 个候选下一步动作；
2. 按达到目标的估计概率给每个候选打分；
3. 并行探索有前景的分支；
4. 路径失败时回溯，不在用户上下文中浪费死胡同内容。

现状 vs MCTS

当前（线性）：

User: "fix the auth bug" │ ▼ Action 1: Read auth.ts ──▶ Action 2: Edit line 45 ──▶ Action 3: Run tests │ Tests fail ✗ │ ▼ Action 4: Try different edit │ Tests fail ✗ │ ▼ Action 5: Read error log... (linear flailing)

采用 MCTS（树搜索）：

User: "fix the auth bug" │ ▼ Read auth.ts │ ├── Branch A: Edit line 45 (score: 0.6) │ └── Run tests → FAIL → prune │ ├── Branch B: Check auth middleware (score: 0.7) ◀── highest score │ └── Edit middleware.ts → Run tests → PASS ✓ │ └── Branch C: Check env config (score: 0.3) └── (not explored — lower score) Result: Branch B succeeds after 2 actions, not 5+

为什么适合 GSD-2

GSD 已具备会话分支原语：

• fork()可从任意消息创建分支——源码确认该方法存在于 agent-session.ts（约 L2694 起），且会向扩展发射session_before_fork/session_fork事件，可被扩展取消；
• 分支摘要（branch summaries）在分支点压缩历史；
• /tree树导航允许用户浏览分支（对应同文件的navigateTree等方法）；
• 会话树已是一等公民概念。

缺口在于：这些原语目前是用户触发的；MCTS 要让 Agent 在解决问题过程中自动触发它们。

架构设计

┌─────────────────────────────────────────────────────────┐ │ MCTS Planning Layer │ │ │ │ ┌─────────────┐ ┌──────────────┐ ┌────────────┐ │ │ │ Proposer │───▶│ Scorer │───▶│ Selector │ │ │ │ Generate N │ │ Estimate P │ │ Pick best │ │ │ │ candidates │ │ of success │ │ to explore │ │ │ └─────────────┘ └──────────────┘ └─────┬──────┘ │ │ │ │ │ ┌─────────────┐ ┌──────────────┐ │ │ │ │ Pruner │◀───│ Executor │◀─────────┘ │ │ │ Kill dead │ │ Run action │ │ │ │ branches │ │ in worktree │ │ │ └─────────────┘ └──────────────┘ │ └─────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────┐ │ Agent Session │ │ (receives winning │ │ branch as result) │ └─────────────────────┘

打分方案

集成点对照

成本收益分析

（上述提升幅度为文档的研究性预估，尚未在仓库中落地验证。）

开放问题

• 何时激活：MCTS 昂贵，是否只在 Agent 检测到难题（反复失败、高不确定性）时激活？
• 分支隔离：Git worktree 能隔离文件变更，但如何隔离 Bash 副作用？
• 预算控制：回退到线性执行前，最多探索多少分支？
• 透明性：用户应看到探索树，还是只看到获胜路径？

优先级矩阵与推荐实施顺序

推荐实施顺序

Phase 1 (Foundation) Phase 2 (Performance) Phase 3 (Intelligence) ───────────────────── ───────────────────── ───────────────────── ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ Skill Library │ │ DAG Tool Exec │ │ Semantic Context│ │ Evolution │──feeds──▶│ │ │ Compression │ │ │ │ Speculative │ │ │ │ │──feeds──▶│ Tool Exec │ │ MCTS Planning │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ ▲ ┌─────────────────┐ │ │ │ Cross-Session │───────────────────┴──────────────────────────┘ │ Learning Graph │ (feeds intelligence layer) └─────────────────┘

• Phase 1（地基）建立反馈闭环，让其他一切随时间变好——技能库进化为 #3、#5、#6 持续供给学习数据；
• Phase 2（性能）带来立即可测的性能收益——DAG 并行与推测执行直接降低每轮延迟；
• Phase 3（智能）需要最大的架构改动，但带来最深的能力提升——语义压缩与 MCTS 规划改变 GSD 在有限上下文预算下的推理方式。

结语：文档与源码的对应关系

这份 Pre-RFC 的价值在于：它没有凭空提概念，而是逐一指认了 GSD-2 现有架构中的挂载点。从当前仓库看，这些挂载点大多真实存在：turn_end/agent_end等扩展事件、fork()与会话树分支原语、compaction.ts中确凿的 chars/4 估算与全有或全无摘要、compaction-orchestrator.ts的编排与session_before_compact钩子、agent-loop.ts中顺序执行工具调用的路径。这六项技术共同构成一条从"性能优化"到"自我进化"的递进路线：先用低成本的并行与推测换取确定性提速，再通过技能进化与学习图建立跨会话的持续学习能力，最后以 MCTS 规划在难题上换取质的突破。读者若想追踪后续落地进展，可在 docs/dev 目录的 ADR 与 RFC 类文档中查找对应决策记录。

• 人工智能
• AI Agent
• 代码智能体
• Agent 编排
• CLI
• AI 应用