尧图网站建设 
人工智能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点击查看免费下载本篇技术指南基于 gsd-2 仓库中 pi-context-optimization-opportunities.md 这一研究专用Research only文档展开。它梳理了 pi 引擎packages/pi-coding-agent与packages/pi-agent-core在上下文工程层面的 10 个优化机会Prompt 缓存、观测掩码、提前压缩阈值、工具结果截断、上下文文件去重、技能懒加载、Token 估算精度、Markdown 化改造、动态工具集以及分阶段成本归因。文中将文档的核心提案与当前仓库源码逐一对照读者读完可以掌握这套上下文成本与质量优化清单的原理、落点位置与实施优先级。文档定位一份未排期实施的上下文工程研究清单原文档开篇即标注了三个关键约束Status: Research only — not planned for implementation.仅研究未计划实施Scope: 影响packages/pi-coding-agent与packages/pi-agent-core的基础设施。受益面: 这些改动将惠及 pi 引擎的每一个消费方而不仅仅是 GSD 本身。这意味着本文讨论的所有优化点应当被理解为审计清单与设计蓝图而非已经落地的功能描述。文章后续章节会对照当前仓库快照指出哪些机会点已具备部分基础设施例如 Anthropic 协议路径上的cache_control哪些仍是纯提案。1. Prompt 缓存cache_control——最高杠杆率的机会现状描述文档指出在理想状态下每次 LLM 调用都会为系统提示词、工具定义和上下文文件重新支付完整的输入 Token 成本因为 API 调用路径上没有设置任何cache_control断点。机会分析Anthropic 的 KV 缓存对缓存命中的 Token 提供 90% 的成本削减0.1x 输入费率。Claude Code 通过将稳定内容置于易变内容之前达成了 92–98% 的缓存命中率。文档给出了三个埋点位置原指packages/pi-ai/src/providers/anthropic.ts协议路径在最后一个工具定义块上设置cache_control: { type: ephemeral }在静态系统提示词部分之后基础样板 上下文文件设置cache_control让每轮的用户消息保持不缓存作为易变后缀。关键约束断点必须位于最后一块静态内容之后缓存断点必须放置在所有静态内容之后、任何动态内容时间戳、按请求变化的变量之前。把一个时间戳移到缓存断点之前会让缓存每次调用都失效。缓存层级关系为tools → system → messages。任何工具定义的变更都会使 system 与 messages 的缓存失效因此工具定义应当按字母序确定性排序避免无谓的缓存抖动。当前仓库对照从当前仓库快照看Anthropic 协议路径已经具备一套完整的缓存控制基础设施集中在 anthropic-shared.tsgetCacheControl()解析缓存保留策略默认short兼容PI_CACHE_RETENTIONlong环境变量直连api.anthropic.com且为 long 时附加ttl: 1hconvertTools()把cache_control打到最后一个工具上覆盖整个工具块convertMessages()在最后一条用户消息与最近的压缩边界消息上各应用一次断点并刻意控制在 Anthropic 4 个断点的上限内system tools boundary last user 4参见 PR #5027 注释buildParams()对 system prompt 块附加cache_controlOAuth 模式下仅让最后一个 system 块携带断点以避免浪费断点槽位。此外仓库还配套了专门的断点测试 anthropic-shared.cache-breakpoint.test.ts。因此可以说文档提出的埋点位置在当前代码中已部分落地工具末块、system、压缩边界、末条消息文档的价值更多体现在审计这些断点是否被动态内容破坏、以及工具排序是否确定性足够强。预期收益多轮会话中GSD auto-mode 的主要成本形态输入 Token 成本可降低 80–90%。2. 消息管线中的观测掩码Observation Masking现状描述文档指出agent-loop.ts在每一轮都把完整的context.messages数组传给 LLM。50 轮之前的工具结果在之后的每一次调用中都被完整重读。AgentContext上的transformContext钩子虽然存在且在每次 LLM 调用前触发但没有默认实现——是否做裁剪完全由扩展自行负责。当前仓库对照transformContext在当前仓库中确实存在且接入了扩展运行时。在 sdk.ts 中可以看到transformContext: async (messages) { const runner extensionRunnerRef.current; if (!runner) return messages; return runner.emitContext(messages); },即默认行为是原样返回消息只有当扩展注册了emitContext处理器时才会被改写——与文档描述完全一致没有默认实现扩展全权负责裁剪。机会与数据JetBrains Research 在 SWE-bench Verified500 个任务最长 250 轮轨迹上的测试表明相比未管理的历史成本降低 50% 以上性能与 LLM 摘要持平或略有超出零额外开销不需要额外的 LLM 调用。提议的默认实现文档给出了一份可在pi-agent-core落地的默认transformContext实现// Keep last KEEP_RECENT_TURNS verbatim; mask older tool results const KEEP_RECENT_TURNS 8; function defaultObservationMask(messages: AgentMessage[]): AgentMessage[] { const cutoff findTurnBoundary(messages, KEEP_RECENT_TURNS); return messages.map((m, i) { if (i cutoff) return m; if (m.type toolResult || m.type bashExecution) { return { ...m, content: [result masked — within summarized history], excludeFromContext: false }; } return m; }); }实现要点保留最近KEEP_RECENT_TURNS8 轮的完整内容只掩码更早的toolResult/bashExecution用轻量占位符替换旧工具结果正文掩码发生在 LLM 调用之前不改写消息存储本身。仓库中与excludeFromContext相关的机制可作参照bashExecution消息已经支持excludeFromContext标记!!前缀在 agent-session.ts 与 convertToLlm() 中都会被过滤说明消息级对 LLM 隐身的通道早已存在观测掩码可以复用这套字段与语义。与压缩的互补关系观测掩码降低了 Token 的累积速率从而推迟压缩阈值被触达。二者是互补的掩码负责稳态压缩负责罕见的超深会话。3. 更早的压缩阈值Earlier Compaction Threshold现状基于固定保留 Token 的触发逻辑当前常量定义在 constants.tsexport const COMPACTION_RESERVE_TOKENS 16_384; export const COMPACTION_KEEP_RECENT_TOKENS 20_000; export const TOOL_RESULT_MAX_CHARS 2_000;按文档计算对于 200K 上下文窗口压缩在约 183K Token 处触发——91.5% 的利用率。保留空间COMPACTION_RESERVE_TOKENS 16_384只是为本次提示 本次响应预留的余量。问题上下文漂移比耗尽更致命文档引用的两个数据点上下文漂移Context drift而非原始耗尽导致约 65% 的企业 Agent 失败根据 Zylos 的生产数据超过约 30K Token 后性能开始可测地退化。当前阈值意味着会话在压缩触发之前会先在一个已经劣化的状态下运行很长一段距离。提议把触发点降到 70% 利用率// Proposed COMPACTION_THRESHOLD_PERCENT 0.70 // fire at 70% of contextWindow COMPACTION_RESERVE_TOKENS contextWindow * (1 - COMPACTION_THRESHOLD_PERCENT)对 200K 窗口约在 140K Token 处压缩比现状提前 43K Token。权衡压缩更频繁但每次发生时上下文里新鲜内容更多摘要质量提升因为每次切割需要丢弃的材料更少仓库测试 compaction-threshold.test.ts 表明阈值是高度可参数化、可单测的行为改动风险可控。4. 工具结果在写入时截断Tool Result Truncation at Write Time现状问题TOOL_RESULT_MAX_CHARS 2_000constants.ts只在压缩摘要期间生效而不是在工具结果进入消息存储时生效。一个返回 50KB 日志输出的 bash 结果会被原样存储并在压缩触发之前逐字逐句地反复重发。从源码看消息渲染层已经存在输出被截断 指向完整输出文件的模式在 messages.ts 中可以看到[Output truncated. Full output: ${msg.fullOutputPath}]。也就是说截断体验的基础设施fullOutputPath 回链已有雏形缺的是在写入消息存储的那一刻就执行截断。两种截断策略策略做法适用硬截断Hard truncation按 N 字符切片追加\n[truncated — {original_length} chars]简单、零开销语义头尾Semantic head/tail保留前 500 字符上下文、命令回显 最后 1000 字符最终输出、错误对 bash 结果更友好因为错误通常在结尾推荐方案以语义头尾为默认策略并按工具类型可配置文件读取类结果受益于头bash/测试输出受益于头 尾。落点建议在 messages.ts 的convertToLlm()或工具结果处理器中。5. 上下文文件去重与裁剪现状按路径去重不按内容去重loadProjectContextFiles()的实现位于 resource-loader.ts核心行为搜索顺序为~/.gsd/agent/agent 目录→ 逐级向上遍历祖先目录 → cwd候选文件名是AGENTS.md与CLAUDE.mdloadContextFileFromDir去重基于seenPaths文件路径 Set不比较内容整个文件内容被逐字拼接到系统提示词中不做裁剪、不做摘要。反模式示例文档给出的反模式如果项目在三个祖先层级仓库根、工作区、家目录各有AGENTS.md三层全部注入若它们共享通用样板内容该内容就被重复注入多次。三个优化方向内容级去重对段落级块做哈希跳过任何在前面文件里已见过的块按章节感知加载解析AGENTS.md中的##标题只包含与当前任务类型相关的章节例如只在运行测试时注入## Testing章节Token 预算强制若全部上下文文件超过 N Token则对最旧/最远的文件做摘要而不是逐字注入。仓库已在其他资源prompts、themes上实现了按名称去重的dedupeResourcesresource-loader.ts说明去重是工程团队认可的模式只是尚未下沉到AGENTS.md的内容层面。6. 技能Skill内容的懒加载与摘要现状当/skill:name被调用时完整技能文件内容会被以内联skill.../skill形式注入到用户消息中参考 skills.ts 的formatSkillsForPrompt技能清单确实以available_skillsskillXML 包裹。没有分块、没有摘要。一个 10KB 的技能文件在那一轮就增加约 2,500 Token。三个机会技能注入缓存如果同一个技能在多个轮次中使用少见但可能每次都重新注入。可以在首次注入后用cache_control缓存技能摘要模式首次引用时只注入 200 Token 的摘要仅当模型通过get_skill_detail工具调用请求时才注入完整内容。对最终未被遵循的技能可显著降本技能预取在已知的长会话开始前例如 auto-mode 启动时预先注入所有可能用到的技能并打上cache_control使整个会话期间技能内容都命中缓存。7. Token 估算精度现状chars / 4启发式当前估算逻辑位于压缩管线compaction.ts以及 compaction/utils.ts 等核心公式为Math.ceil(chars / 4)。文档指出该启发式的两个系统性偏差对英文散文高估实际约 3.5 字符/Token对短标识符代码或 Unicode 内容低估。机会引入真正的分词器anthropic-ai/tokenizertiktoken 兼容随 SDK 分发准确但单次调用约 5ms分层策略展示用chars/4只有在需要做压缩阈值决策的地方准确率关键才使用真正的分词器。收益更精确的压缩触发时机、更少的无谓压缩、COMPACTION_KEEP_RECENT_TOKENS边界放置更准确。8. 格式内部上下文用 Markdown 替代 XML现状消息管线在多处使用skill、summary、compaction等 XML 包裹前述 skills.ts 即为实例而系统提示词各章节大都是散文式 Markdown。调研结论XML 成对的开闭标签让同等语义内容多消耗15–40%的 Token但 Claude 针对 XML 做过优化在需要精确段落解析的任务上准确率更高。建议的转换原则转换到 Markdown 的场景内容非嵌套扁平指令、状态消息面向人类可读而非被模型机器解析不需要精确的边界检测。保留 XML 的场景边界模糊的 few-shot 示例技能内容需要与周围文本精确隔离压缩摘要模型必须将其视为权威历史。预估收益系统提示词 Token 数降低5–15%。9. 动态工具集交付Dynamic Tool Set Delivery现状所有工具定义都出现在每一次 LLM 请求中。在静态配置下工具描述消耗输入 Token 的 60–80%随着新扩展注册工具基线线性增长。这解释了为何工具定义排序见第 1 节如此关键——任何工具变更都会波及 system 与 messages 缓存。机会三函数动态工具集模式search_tools(query)— 对工具目录做语义搜索describe_tools(ids[])— 按需拉取完整 schemaexecute_tool(id, params)— 执行保持不变。文档引用 Speakeasy 的测量Token 削减 91–97%任务成功率 100%。代价是工具调用次数增加 2–3 倍、墙钟时间延长约 50%但净成本显著下降。对 pi 的可行性评估文档认为工程主体在于语义搜索索引与describe_tools/search_tools两个工具的实现——前提是工具注册表已经把工具元数据与定义分离存储。需要注意文档所引用的packages/pi-coding-agent/src/core/tool-registry.ts路径在当前仓库快照中未被确认到建议以仓库实际结构为准核对工具/命令的注册与冲突检测可见 resource-loader.ts 的detectExtensionConflicts实现。10. 成本归因与分阶段报告Cost Attribution现状SessionManager.getUsageTotals()session-manager.ts在整个会话层面累计成本不保存任何分阶段或分 Agent 的细分。成本可见性仅限于 footer 总数与GSD_SHOW_TOKEN_COST1的逐轮展示。机会结构化的成本检查点事件interface CostCheckpointEvent { type: cost_checkpoint; label: string; // discuss-phase, execute-slice-3 deltaTokens: Usage; // tokens since last checkpoint cumulativeTokens: Usage; cumulativeCost: number; }消费场景GSD 扩展可以订阅这些事件在/gsd stats中呈现每个里程碑的成本并标记成本异常偏高的里程碑——从而实现预算感知的规划budget-aware planning。实施优先级总览文档末尾给出了如追求实施时的完整排序表优先级项目工作量预期影响1Prompt 缓存cache_control低输入成本降低 80–90%2提前压缩阈值70%极低降低长会话中的漂移3工具结果写入时截断低压缩间隙之间的上下文膨胀更小4上下文文件去重中不固定——多级 AGENTS.md 场景收益高5观测掩码默认transformContext中长期运行的 Agent 成本降低 50%6Token 估算真正分词器低精度提升成本影响较小7Markdown 替代 XML 审计低系统提示词降低 5–15%8技能cache_control缓存低技能密集型会话收益明显9动态工具集交付高大型工具目录降低 90%重大架构变更10分阶段成本归因事件中仅提升可见性为未来预算路由铺路不难看出一个清晰的模式前三个项目都是低工作量、高收益的立即可做项而动态工具集与成本归因属于中期架构级投入。结合第 1 节我们已验证的现状cache_control基础设施在 Anthropic 协议路径上已经就位接下来真正值得投入的是把断点纪律静态内容在前、工具确定性排序固化成可测试的约束并推动 70% 压缩阈值与写入时截断这两个低成本的稳态优化。延伸阅读完整原始研究文档pi-context-optimization-opportunities.md压缩与保留相关常量constants.tsAnthropic 协议缓存控制实现与测试anthropic-shared.ts / anthropic-shared.cache-breakpoint.test.ts消息存储与 LLM 转换messages.ts上下文文件加载与去重resource-loader.ts压缩触发与 Token 估算compaction.tstransformContext扩展钩子接线sdk.ts会话成本累计session-manager.ts说明本文所引文档标注为 Research only所有预期收益/降低百分比均为文档引用或基于其调研来源的表述当前仓库的实际行为以源码与测试为准实施前建议按仓库最新代码重新核算。赞分享人工智能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点击查看免费下载相关推荐aider 提示词缓存Prompt Caching完全指南从成本优化到缓存保温的实现原理aider 提示词缓存Prompt Caching完全指南从成本优化到缓存保温的实现原理 aider 是运行在终端里的 AI 结对编程工具它会将系统提示人工智能大模型AI Agent代码智能体交互助手CLI开发工具MiroThinker缓存机制减少重复工具调用提升效率的技巧MiroThinker缓存机制减少重复工具调用提升效率的技巧 MiroThinker是一款为深度研究和复杂工具使用场景训练的开源智能体模型其高效的缓存机制能人工智能大模型AI Agent深度研究Agent 框架MCP 服务工具调用模型评测Plandex成本优化方案上下文缓存降低API调用Plandex成本优化方案上下文缓存降低API调用 痛点AI开发工具的高昂API成本 在AI辅助开发日益普及的今天开发者们面临着一个共同的挑战API调用人工智能AI Agent代码智能体CLI开发工具上一篇Mermaid Live Editor 免费在线图表编辑器完整指南改图为什么能像改文档下一篇Czkawka:免费开源的磁盘清理工具,一次扫描找出重复文件、相似图片和空文件夹创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 pi-coding-agent 上下文优化全景：从 Prompt 缓存到动态工具集的 10 个成本与质量优化点
人工智能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点击查看免费下载本篇技术指南基于 gsd-2 仓库中 pi-context-optimization-opportunities.md 这一研究专用Research only文档展开。它梳理了 pi 引擎packages/pi-coding-agent与packages/pi-agent-core在上下文工程层面的 10 个优化机会Prompt 缓存、观测掩码、提前压缩阈值、工具结果截断、上下文文件去重、技能懒加载、Token 估算精度、Markdown 化改造、动态工具集以及分阶段成本归因。文中将文档的核心提案与当前仓库源码逐一对照读者读完可以掌握这套上下文成本与质量优化清单的原理、落点位置与实施优先级。文档定位一份未排期实施的上下文工程研究清单原文档开篇即标注了三个关键约束Status: Research only — not planned for implementation.仅研究未计划实施Scope: 影响packages/pi-coding-agent与packages/pi-agent-core的基础设施。受益面: 这些改动将惠及 pi 引擎的每一个消费方而不仅仅是 GSD 本身。这意味着本文讨论的所有优化点应当被理解为审计清单与设计蓝图而非已经落地的功能描述。文章后续章节会对照当前仓库快照指出哪些机会点已具备部分基础设施例如 Anthropic 协议路径上的cache_control哪些仍是纯提案。1. Prompt 缓存cache_control——最高杠杆率的机会现状描述文档指出在理想状态下每次 LLM 调用都会为系统提示词、工具定义和上下文文件重新支付完整的输入 Token 成本因为 API 调用路径上没有设置任何cache_control断点。机会分析Anthropic 的 KV 缓存对缓存命中的 Token 提供 90% 的成本削减0.1x 输入费率。Claude Code 通过将稳定内容置于易变内容之前达成了 92–98% 的缓存命中率。文档给出了三个埋点位置原指packages/pi-ai/src/providers/anthropic.ts协议路径在最后一个工具定义块上设置cache_control: { type: ephemeral }在静态系统提示词部分之后基础样板 上下文文件设置cache_control让每轮的用户消息保持不缓存作为易变后缀。关键约束断点必须位于最后一块静态内容之后缓存断点必须放置在所有静态内容之后、任何动态内容时间戳、按请求变化的变量之前。把一个时间戳移到缓存断点之前会让缓存每次调用都失效。缓存层级关系为tools → system → messages。任何工具定义的变更都会使 system 与 messages 的缓存失效因此工具定义应当按字母序确定性排序避免无谓的缓存抖动。当前仓库对照从当前仓库快照看Anthropic 协议路径已经具备一套完整的缓存控制基础设施集中在 anthropic-shared.tsgetCacheControl()解析缓存保留策略默认short兼容PI_CACHE_RETENTIONlong环境变量直连api.anthropic.com且为 long 时附加ttl: 1hconvertTools()把cache_control打到最后一个工具上覆盖整个工具块convertMessages()在最后一条用户消息与最近的压缩边界消息上各应用一次断点并刻意控制在 Anthropic 4 个断点的上限内system tools boundary last user 4参见 PR #5027 注释buildParams()对 system prompt 块附加cache_controlOAuth 模式下仅让最后一个 system 块携带断点以避免浪费断点槽位。此外仓库还配套了专门的断点测试 anthropic-shared.cache-breakpoint.test.ts。因此可以说文档提出的埋点位置在当前代码中已部分落地工具末块、system、压缩边界、末条消息文档的价值更多体现在审计这些断点是否被动态内容破坏、以及工具排序是否确定性足够强。预期收益多轮会话中GSD auto-mode 的主要成本形态输入 Token 成本可降低 80–90%。2. 消息管线中的观测掩码Observation Masking现状描述文档指出agent-loop.ts在每一轮都把完整的context.messages数组传给 LLM。50 轮之前的工具结果在之后的每一次调用中都被完整重读。AgentContext上的transformContext钩子虽然存在且在每次 LLM 调用前触发但没有默认实现——是否做裁剪完全由扩展自行负责。当前仓库对照transformContext在当前仓库中确实存在且接入了扩展运行时。在 sdk.ts 中可以看到transformContext: async (messages) { const runner extensionRunnerRef.current; if (!runner) return messages; return runner.emitContext(messages); },即默认行为是原样返回消息只有当扩展注册了emitContext处理器时才会被改写——与文档描述完全一致没有默认实现扩展全权负责裁剪。机会与数据JetBrains Research 在 SWE-bench Verified500 个任务最长 250 轮轨迹上的测试表明相比未管理的历史成本降低 50% 以上性能与 LLM 摘要持平或略有超出零额外开销不需要额外的 LLM 调用。提议的默认实现文档给出了一份可在pi-agent-core落地的默认transformContext实现// Keep last KEEP_RECENT_TURNS verbatim; mask older tool results const KEEP_RECENT_TURNS 8; function defaultObservationMask(messages: AgentMessage[]): AgentMessage[] { const cutoff findTurnBoundary(messages, KEEP_RECENT_TURNS); return messages.map((m, i) { if (i cutoff) return m; if (m.type toolResult || m.type bashExecution) { return { ...m, content: [result masked — within summarized history], excludeFromContext: false }; } return m; }); }实现要点保留最近KEEP_RECENT_TURNS8 轮的完整内容只掩码更早的toolResult/bashExecution用轻量占位符替换旧工具结果正文掩码发生在 LLM 调用之前不改写消息存储本身。仓库中与excludeFromContext相关的机制可作参照bashExecution消息已经支持excludeFromContext标记!!前缀在 agent-session.ts 与 convertToLlm() 中都会被过滤说明消息级对 LLM 隐身的通道早已存在观测掩码可以复用这套字段与语义。与压缩的互补关系观测掩码降低了 Token 的累积速率从而推迟压缩阈值被触达。二者是互补的掩码负责稳态压缩负责罕见的超深会话。3. 更早的压缩阈值Earlier Compaction Threshold现状基于固定保留 Token 的触发逻辑当前常量定义在 constants.tsexport const COMPACTION_RESERVE_TOKENS 16_384; export const COMPACTION_KEEP_RECENT_TOKENS 20_000; export const TOOL_RESULT_MAX_CHARS 2_000;按文档计算对于 200K 上下文窗口压缩在约 183K Token 处触发——91.5% 的利用率。保留空间COMPACTION_RESERVE_TOKENS 16_384只是为本次提示 本次响应预留的余量。问题上下文漂移比耗尽更致命文档引用的两个数据点上下文漂移Context drift而非原始耗尽导致约 65% 的企业 Agent 失败根据 Zylos 的生产数据超过约 30K Token 后性能开始可测地退化。当前阈值意味着会话在压缩触发之前会先在一个已经劣化的状态下运行很长一段距离。提议把触发点降到 70% 利用率// Proposed COMPACTION_THRESHOLD_PERCENT 0.70 // fire at 70% of contextWindow COMPACTION_RESERVE_TOKENS contextWindow * (1 - COMPACTION_THRESHOLD_PERCENT)对 200K 窗口约在 140K Token 处压缩比现状提前 43K Token。权衡压缩更频繁但每次发生时上下文里新鲜内容更多摘要质量提升因为每次切割需要丢弃的材料更少仓库测试 compaction-threshold.test.ts 表明阈值是高度可参数化、可单测的行为改动风险可控。4. 工具结果在写入时截断Tool Result Truncation at Write Time现状问题TOOL_RESULT_MAX_CHARS 2_000constants.ts只在压缩摘要期间生效而不是在工具结果进入消息存储时生效。一个返回 50KB 日志输出的 bash 结果会被原样存储并在压缩触发之前逐字逐句地反复重发。从源码看消息渲染层已经存在输出被截断 指向完整输出文件的模式在 messages.ts 中可以看到[Output truncated. Full output: ${msg.fullOutputPath}]。也就是说截断体验的基础设施fullOutputPath 回链已有雏形缺的是在写入消息存储的那一刻就执行截断。两种截断策略策略做法适用硬截断Hard truncation按 N 字符切片追加\n[truncated — {original_length} chars]简单、零开销语义头尾Semantic head/tail保留前 500 字符上下文、命令回显 最后 1000 字符最终输出、错误对 bash 结果更友好因为错误通常在结尾推荐方案以语义头尾为默认策略并按工具类型可配置文件读取类结果受益于头bash/测试输出受益于头 尾。落点建议在 messages.ts 的convertToLlm()或工具结果处理器中。5. 上下文文件去重与裁剪现状按路径去重不按内容去重loadProjectContextFiles()的实现位于 resource-loader.ts核心行为搜索顺序为~/.gsd/agent/agent 目录→ 逐级向上遍历祖先目录 → cwd候选文件名是AGENTS.md与CLAUDE.mdloadContextFileFromDir去重基于seenPaths文件路径 Set不比较内容整个文件内容被逐字拼接到系统提示词中不做裁剪、不做摘要。反模式示例文档给出的反模式如果项目在三个祖先层级仓库根、工作区、家目录各有AGENTS.md三层全部注入若它们共享通用样板内容该内容就被重复注入多次。三个优化方向内容级去重对段落级块做哈希跳过任何在前面文件里已见过的块按章节感知加载解析AGENTS.md中的##标题只包含与当前任务类型相关的章节例如只在运行测试时注入## Testing章节Token 预算强制若全部上下文文件超过 N Token则对最旧/最远的文件做摘要而不是逐字注入。仓库已在其他资源prompts、themes上实现了按名称去重的dedupeResourcesresource-loader.ts说明去重是工程团队认可的模式只是尚未下沉到AGENTS.md的内容层面。6. 技能Skill内容的懒加载与摘要现状当/skill:name被调用时完整技能文件内容会被以内联skill.../skill形式注入到用户消息中参考 skills.ts 的formatSkillsForPrompt技能清单确实以available_skillsskillXML 包裹。没有分块、没有摘要。一个 10KB 的技能文件在那一轮就增加约 2,500 Token。三个机会技能注入缓存如果同一个技能在多个轮次中使用少见但可能每次都重新注入。可以在首次注入后用cache_control缓存技能摘要模式首次引用时只注入 200 Token 的摘要仅当模型通过get_skill_detail工具调用请求时才注入完整内容。对最终未被遵循的技能可显著降本技能预取在已知的长会话开始前例如 auto-mode 启动时预先注入所有可能用到的技能并打上cache_control使整个会话期间技能内容都命中缓存。7. Token 估算精度现状chars / 4启发式当前估算逻辑位于压缩管线compaction.ts以及 compaction/utils.ts 等核心公式为Math.ceil(chars / 4)。文档指出该启发式的两个系统性偏差对英文散文高估实际约 3.5 字符/Token对短标识符代码或 Unicode 内容低估。机会引入真正的分词器anthropic-ai/tokenizertiktoken 兼容随 SDK 分发准确但单次调用约 5ms分层策略展示用chars/4只有在需要做压缩阈值决策的地方准确率关键才使用真正的分词器。收益更精确的压缩触发时机、更少的无谓压缩、COMPACTION_KEEP_RECENT_TOKENS边界放置更准确。8. 格式内部上下文用 Markdown 替代 XML现状消息管线在多处使用skill、summary、compaction等 XML 包裹前述 skills.ts 即为实例而系统提示词各章节大都是散文式 Markdown。调研结论XML 成对的开闭标签让同等语义内容多消耗15–40%的 Token但 Claude 针对 XML 做过优化在需要精确段落解析的任务上准确率更高。建议的转换原则转换到 Markdown 的场景内容非嵌套扁平指令、状态消息面向人类可读而非被模型机器解析不需要精确的边界检测。保留 XML 的场景边界模糊的 few-shot 示例技能内容需要与周围文本精确隔离压缩摘要模型必须将其视为权威历史。预估收益系统提示词 Token 数降低5–15%。9. 动态工具集交付Dynamic Tool Set Delivery现状所有工具定义都出现在每一次 LLM 请求中。在静态配置下工具描述消耗输入 Token 的 60–80%随着新扩展注册工具基线线性增长。这解释了为何工具定义排序见第 1 节如此关键——任何工具变更都会波及 system 与 messages 缓存。机会三函数动态工具集模式search_tools(query)— 对工具目录做语义搜索describe_tools(ids[])— 按需拉取完整 schemaexecute_tool(id, params)— 执行保持不变。文档引用 Speakeasy 的测量Token 削减 91–97%任务成功率 100%。代价是工具调用次数增加 2–3 倍、墙钟时间延长约 50%但净成本显著下降。对 pi 的可行性评估文档认为工程主体在于语义搜索索引与describe_tools/search_tools两个工具的实现——前提是工具注册表已经把工具元数据与定义分离存储。需要注意文档所引用的packages/pi-coding-agent/src/core/tool-registry.ts路径在当前仓库快照中未被确认到建议以仓库实际结构为准核对工具/命令的注册与冲突检测可见 resource-loader.ts 的detectExtensionConflicts实现。10. 成本归因与分阶段报告Cost Attribution现状SessionManager.getUsageTotals()session-manager.ts在整个会话层面累计成本不保存任何分阶段或分 Agent 的细分。成本可见性仅限于 footer 总数与GSD_SHOW_TOKEN_COST1的逐轮展示。机会结构化的成本检查点事件interface CostCheckpointEvent { type: cost_checkpoint; label: string; // discuss-phase, execute-slice-3 deltaTokens: Usage; // tokens since last checkpoint cumulativeTokens: Usage; cumulativeCost: number; }消费场景GSD 扩展可以订阅这些事件在/gsd stats中呈现每个里程碑的成本并标记成本异常偏高的里程碑——从而实现预算感知的规划budget-aware planning。实施优先级总览文档末尾给出了如追求实施时的完整排序表优先级项目工作量预期影响1Prompt 缓存cache_control低输入成本降低 80–90%2提前压缩阈值70%极低降低长会话中的漂移3工具结果写入时截断低压缩间隙之间的上下文膨胀更小4上下文文件去重中不固定——多级 AGENTS.md 场景收益高5观测掩码默认transformContext中长期运行的 Agent 成本降低 50%6Token 估算真正分词器低精度提升成本影响较小7Markdown 替代 XML 审计低系统提示词降低 5–15%8技能cache_control缓存低技能密集型会话收益明显9动态工具集交付高大型工具目录降低 90%重大架构变更10分阶段成本归因事件中仅提升可见性为未来预算路由铺路不难看出一个清晰的模式前三个项目都是低工作量、高收益的立即可做项而动态工具集与成本归因属于中期架构级投入。结合第 1 节我们已验证的现状cache_control基础设施在 Anthropic 协议路径上已经就位接下来真正值得投入的是把断点纪律静态内容在前、工具确定性排序固化成可测试的约束并推动 70% 压缩阈值与写入时截断这两个低成本的稳态优化。延伸阅读完整原始研究文档pi-context-optimization-opportunities.md压缩与保留相关常量constants.tsAnthropic 协议缓存控制实现与测试anthropic-shared.ts / anthropic-shared.cache-breakpoint.test.ts消息存储与 LLM 转换messages.ts上下文文件加载与去重resource-loader.ts压缩触发与 Token 估算compaction.tstransformContext扩展钩子接线sdk.ts会话成本累计session-manager.ts说明本文所引文档标注为 Research only所有预期收益/降低百分比均为文档引用或基于其调研来源的表述当前仓库的实际行为以源码与测试为准实施前建议按仓库最新代码重新核算。赞分享人工智能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点击查看免费下载相关推荐aider 提示词缓存Prompt Caching完全指南从成本优化到缓存保温的实现原理aider 提示词缓存Prompt Caching完全指南从成本优化到缓存保温的实现原理 aider 是运行在终端里的 AI 结对编程工具它会将系统提示人工智能大模型AI Agent代码智能体交互助手CLI开发工具MiroThinker缓存机制减少重复工具调用提升效率的技巧MiroThinker缓存机制减少重复工具调用提升效率的技巧 MiroThinker是一款为深度研究和复杂工具使用场景训练的开源智能体模型其高效的缓存机制能人工智能大模型AI Agent深度研究Agent 框架MCP 服务工具调用模型评测Plandex成本优化方案上下文缓存降低API调用Plandex成本优化方案上下文缓存降低API调用 痛点AI开发工具的高昂API成本 在AI辅助开发日益普及的今天开发者们面临着一个共同的挑战API调用人工智能AI Agent代码智能体CLI开发工具上一篇Mermaid Live Editor 免费在线图表编辑器完整指南改图为什么能像改文档下一篇Czkawka:免费开源的磁盘清理工具,一次扫描找出重复文件、相似图片和空文件夹创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考