人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载本文基于仓库 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 的运行方式发生质变。六项技术被分为三个类别类别技术主题自我进化Self-Improvement技能库进化Skill Library Evolution、跨会话学习图Cross-Session Learning GraphGSD 用得越多越聪明性能PerformanceDAG 工具执行DAG Tool Execution、推测性工具执行Speculative Tool ExecutionGSD 每轮更快智能Intelligence语义上下文压缩Semantic Context Compression、MCTS 规划MCTS Planning在相同上下文预算下推理更好需要强调的是这些技术多数处于研究建议层面尚未全部落地文档中引用的外部论文与行业资料如 SkillRL、LLMCompiler、Speculative Tool Calls 等属于背景依据本文不展开外部链接读者如需深入研究可自行检索相应关键词。源码中已确认的事实如 chars/4 估算逻辑、压缩参数默认值、fork()等原语将标注对应仓库路径。1. 技能库进化Skill Library Evolution——优先级 #1类别自我进化影响巨大Massive工作量中等优先级第 1核心思想文档参考了 SkillRLICLR 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 │ │ │ └─────────────────────────────────────────────────────────┘学习到的知识分为两类类型描述示例通用技能General Skills跨任务适用的通用策略指导编辑 TypeScript 文件前先通过 LSP 检查类型错误任务特定技能Task-Specific Skills针对特定技能领域的类别级启发式fix-issue技能应该在开 PR 之前检查 CI 状态而不是之后为什么适合 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 │ └─────────────────────────────────────────────┘集成点对照GSD 组件集成角色agent-session.ts→turn_end事件捕获执行结果成功/失败信号扩展钩子agent_end触发轨迹蒸馏技能文件系统接收带学习模式的版本化更新compaction.ts提供会话中的轨迹数据供蒸馏使用开放问题漂移防护如何防止积累的学习内容淹没原始技能意图冲突解决一个会话学到的教训与另一会话相矛盾时怎么办质量门更新写入前是否需要一次校验 pass2. 基于 DAG 的并行工具执行DAG-Based Parallel Tool Execution——优先级 #2类别性能影响高工作量中等优先级第 2核心思想文档借鉴 LLM Compiler 模式ICML 2024把多工具工作流当成一次编译器优化 pass。当模型在单次响应中返回多个工具调用时系统不再顺序执行而是分析工具调用之间的依赖关系构造有向无环图DAG并行执行相互独立的工具只在存在真实数据依赖时阻塞。现状 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)依赖分析规则工具 A工具 B有依赖原因Read(file)Read(file)否读操作是幂等的Read(file)Grep(pattern)否独立数据源Read(file)Edit(file)是编辑依赖读取的内容Edit(file)Edit(file)是对同一文件的编辑必须串行Bash(cmd)Bash(cmd)可能取决于副作用Write(file)Read(file)是写后的读必须等写完成为什么适合 GSD-2模型在单次响应中已经会发出多个tool_use块但当前执行路径在 agent-loop.ts 中按顺序处理。文档估算一个典型编码轮次包含 3-5 个工具调用其中约 60% 可并行化读、grep、glob每轮延迟可下降 40-60%一个 50 轮会话可省下数分钟。此处的40-60%是文档的估算值属于研究性推测未在仓库中有基准测试佐证。集成点对照GSD 组件集成角色agent-loop.ts工具执行路径用 DAG 调度器替换顺序执行工具定义为工具标注副作用元数据纯/非纯扩展钩子tool_*必须按依赖链保持正确触发顺序架构设计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 │ └─────────────────────────────────────────────────────────────┘预测策略从简到繁策略描述预期命中率关键词提取解析用户提示中的文件路径、函数名 → 预读这些文件40-60%会话历史记录哪些工具跟随哪些用户提示模式50-70%学习模式利用技能库进化数据预测工具序列60-80%模型预查询用快速/廉价模型预测工具调用70-85%命中率为文档研究的预期区间属待验证数据。为什么适合 GSD-2GSD 的最大延迟瓶颈是往返链路用户提示 → 模型思考 → 模型请求工具 → 工具执行 → 结果回传 → 模型再思考。推测执行直击最高延迟环节。文档认为现有架构让这一功能易于添加AgentSession.prompt()在发给模型之前已经处理用户输入对应 agent-session.ts 的会话处理链路工具结果已缓存在消息数组中扩展系统可拦截输入并触发预取。集成点对照GSD 组件集成角色AgentSession.prompt()在用户输入之后、模型调用之前触发推测工具结果缓存新增以 toolargs 为键存储推测结果agent-loop.ts工具执行执行前先查缓存命中即返回扩展钩子input解析用户意图中的文件路径、模式架构设计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 │ └───────────────┘成本分析场景成本预测正确延迟约 0ms结果已就绪。计算成本 预执行本身对 Read/Grep 可忽略预测错误预执行工具的计算被浪费。对 Read/Grep/Glob 而言不足 10ms 的 I/O部分命中只要命中率 20%净收益为正因为未命中的代价极低开放问题缓存 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 token 估算约 25% 高估 → 过早压缩 → 浪费上下文compaction.ts:201-259全有或全无的摘要丢失后续可能相关的具体细节compaction.ts:327-400压缩历史无法检索一旦摘要细节永久丢失compaction-orchestrator.ts源码验证当前仓库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.tsCOMPACTION_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 users 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方案准确度成本char/4当前约 75%高估零Provider 上报的 usage100%仅上一轮零已在跟踪tiktoken / provider tokenizer约 98%每条消息约 5ms混合近期用实际值旧消息用 char/4约 95%可忽略文档强调混合方案——近期消息使用 provider 响应中的实际 token 数、旧消息回退到 char/4——是无需新增依赖即可快速见效的方案。这一点在当前源码中已有雏形estimateContextTokens()见 compaction/compaction.ts 约 L168-L196正是优先使用最近一条有效 assistant usage其后消息再逐条估算的混合思路calculateContextTokens()只统计input cacheRead cacheWrite排除输出 token。集成点对照GSD 组件集成角色compaction.ts用分层方案替换截断点算法compaction-orchestrator.ts在模型调用前加入 warm-tier 检索agent-session.ts消息构建注入检索到的 warm-tier 片段会话持久化层将 embedding 与会话条目一同存储开放问题Embedding 模型本地快、私有还是 API质量好、有延迟索引格式扁平数组上简单余弦相似度还是 HNSW 索引检索预算每轮给 warm-tier 检索分配多少 token连贯性如何防止检索到的历史上下文混淆模型对当前状态的判断5. 跨会话学习图Cross-Session Learning Graph——优先级 #5类别自我进化影响变革性Transformative工作量高优先级第 5核心思想GSD 当前记忆系统MEMORY.md 独立文件存储的是扁平、基于文件的记忆。学习图把它扩展为结构化知识库捕获跨所有会话的代码库—文件—错误—解决方案—模式之间的关系网络。文档引用了 Agent Memory 研究与 context engineering 文献作为背景。当前记忆 vs 学习图维度当前MEMORY.md学习图结构扁平文件列表节点 边图关系无文件 X 常在 Y 变化时出错检索全部加载进上下文查询驱动只加载相关节点学习手动用户说记住 X从执行结果自动学习范围按项目目录按项目并含跨项目模式过时处理手动清理随时间置信度衰减图 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 │ └──────────┘ └──────────┘示例查询查询结果auth.ts中出现过哪些错误连接到该文件节点的错误节点列表这个代码库里TypeError的典型修法是什么该错误类型成功率最高的 Solution 节点哪些文件倾向于一起出问题错误会话中高共现的文件簇这个项目里哪些工具最慢按平均执行时间排序的 Tool 节点集成点对照GSD 组件集成角色session-manager.ts会话保存时写入图节点agent-session.tsprompt 构建模型调用前查询图获取相关上下文记忆系统MEMORY.md共存——图处理结构化知识记忆处理偏好/反馈扩展钩子agent_end用会话结果触发图更新存储选型方案优点缺点SQLite json 列简单、零依赖、查询快无原生向量检索SQLite sqlite-vss为 SQLite 增加向量相似度额外原生依赖扁平 JSON 文件零依赖、对 git 友好大图时查询慢LanceDB嵌入式向量库、无需服务额外依赖开放问题隐私图包含详细的代码库交互历史静止时是否应加密可移植性图随项目走.claude/目录还是留在用户本地垃圾回收如何剪除过期节点例如已不存在的文件6. 基于 MCTS 的规划MCTS-Based Planning——优先级 #6类别智能影响变革性工作量非常高优先级第 6核心思想受 ToolTree 与蒙特卡洛树搜索MCTS启发该技术把 GSD 的线性动作选择替换为树形规划器同时探索多条解决路径生成 N 个候选下一步动作按达到目标的估计概率给每个候选打分并行探索有前景的分支路径失败时回溯不在用户上下文中浪费死胡同内容。现状 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-2GSD 已具备会话分支原语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) │ └─────────────────────┘打分方案方案速度质量成本启发式文件相关性、错误邻近度快低免费快速模型haiku 级模型给候选打分中中低自评主模型评估自己的提案慢高高学习型打分器基于学习图历史结果训练快高推理时免费集成点对照GSD 组件集成角色agent-loop.ts在用户提示与动作执行之间新增规划阶段会话分支fork()用于创建探索分支Git worktree每个分支在隔离 worktree 中探索agent-session.ts接收获胜分支并以结果形式呈现技能库进化#1提供学习到的模式随时间改进打分器成本收益分析因素数值每轮 LLM 调用增加 2-5 倍提案生成 打分Token 用量复杂问题增加 3-10 倍难题成功率预估提升 30-50%解题时间每轮 LLM 调用更多但总轮次更少用户体验Agent 在难题上表现为思考更深上述提升幅度为文档的研究性预估尚未在仓库中落地验证。开放问题何时激活MCTS 昂贵是否只在 Agent 检测到难题反复失败、高不确定性时激活分支隔离Git worktree 能隔离文件变更但如何隔离 Bash 副作用预算控制回退到线性执行前最多探索多少分支透明性用户应看到探索树还是只看到获胜路径优先级矩阵与推荐实施顺序#技术影响工作量复合效应依赖1技能库进化巨大中等是——改善所有其他技术无2DAG 工具执行高中等否——静态提速无3推测性工具执行高低-中是——随学习改进受益于 #14语义上下文压缩高高否——静态改进无5跨会话学习图变革性高是——反哺 #1、#3、#6受益于 #16MCTS 规划变革性非常高是——随 #1、#5 改进受益于 #1、#5推荐实施顺序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 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐torchao最新研究进展前沿量化技术解读torchao最新研究进展前沿量化技术解读 在大语言模型LLM应用中量化技术是平衡性能与效率的关键。随着模型参数量呈指数级增长原生PyTorch库 tAbpHelper.GUI实战案例从零构建电商ABP应用的终极指南AbpHelper.GUI实战案例从零构建电商ABP应用的终极指南 想要快速构建企业级ABP应用却苦于重复的CRUD代码编写AbpHelper.GUI是你的Meetily路线图2025功能规划与技术演进Meetily路线图2025功能规划与技术演进 引言隐私优先的会议智能新纪元 你是否仍在为这些会议挑战而困扰敏感信息暴露风险、云端处理延迟、定制化需求受限人工智能AI 应用语音本地部署桌面应用上一篇art-template前端监控用户体验数据分析下一篇TestCafe 与 Vue.js 应用测试组件交互与状态管理测试指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考