Agent Skills 到 X-to-Book 系统的技能映射实战用 Context Engineering 设计多智能体内容生产线【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering导读本文深入解析examples/x-to-book-system/SKILLS-MAPPING.md——一份将 Agent Skills for Context Engineering 仓库中的六个核心技能multi-agent-patterns、context-fundamentals、memory-systems、context-optimization、tool-design、evaluation逐一映射到 X-to-Book 多智能体系统设计决策的对照文档。该示例系统用于每日监控指定 XTwitter账号、合成其内容并生成结构化书籍。读完本文你将掌握如何基于技能原则做多智能体架构选型、为每个 Agent 分配显式上下文预算、选择时序知识图谱作为记忆层、用观察掩蔽与压缩对抗 10 万级 token 的社交媒体数据洪流、按合并原则收敛工具集以及用五维加权评分卡做质量门禁。一、文档定位技能库与产品需求之间的“翻译层”SKILLS-MAPPING.md 是整个示例的核心“接线图”。它解决一个实际问题技能仓库提供了大量 context engineering 的模式与原则但每个模式在具体项目中该不该用、用在哪个决策点上需要一份显式的对照表来约束。文档以“技能 → 概念 → PRD 落地”三列结构组织把六条技能分别映射到 X-to-Book 系统 PRD 的具体设计决策上并在末尾给出跨技能集成矩阵说明这些模式如何协同工作。该示例的完整背景与使用方式见 examples/x-to-book-system/README.md其核心定位是把技能库当作“词汇与模式”把具体项目当作“约束下的应用”。二、技能映射总览SKILLS-MAPPING.md 覆盖了 6 项技能每项对应系统中的一个核心设计决策技能Skill对应核心决策multi-agent-patterns选择 Supervisor/Orchestrator 架构 文件系统协调context-fundamentals按角色分配显式 token 预算 渐进式披露memory-systems选择时序知识图谱Temporal Knowledge Graphcontext-optimization观察掩蔽 70% 压缩触发 KV-cache 排序tool-design3 个合并工具替代 15 窄工具evaluation五维加权评分 自动/人工评估流水线下面逐一展开每条映射都补充了技能原文的原理依据与 PRD 中的落地代码。三、multi-agent-patterns为什么选 Supervisor/Orchestrator3.1 概念映射概念技能原文要点PRD 落地Supervisor 模式“supervisor pattern places a central agent in control, delegating to specialists and synthesizing results.”Orchestrator 协调 Scraper、Analyzer、Synthesizer、Writer、Editor 五个专家 Agent上下文隔离“Sub-agents exist primarily to isolate context, not to anthropomorphize role division.”每个 Agent 在聚焦自身阶段的干净上下文中运行电话游戏问题“LangGraph benchmarks found supervisor architectures initially performed 50% worse due to the telephone game problem where supervisors paraphrase sub-agent responses incorrectly.”各阶段输出写入文件系统而非经由 Orchestrator 转述合成文件系统协调“For complex tasks requiring shared state, agents read and write to persistent storage.”所有 Agent 间数据流经文件系统监督者瓶颈缓解“Implement output schema constraints so workers return only distilled summaries.”Orchestrator 只接收阶段摘要绝不接收原始数据关键洞察来自 skills/multi-agent-patterns/SKILL.md多智能体架构的首要收益是上下文隔离而不是“拟人化地分工”。X-to-Book 的场景正好符合该技能的激活条件——单 Agent 上下文无法容纳高量社交媒体数据、任务可自然分解为顺序阶段、各阶段需要不同的工具集与系统提示词。3.2 三种模式的选择逻辑multi-agent-patterns 技能 描述了三种主导模式映射文档完整记录了每种模式“何时使用”的判定Supervisor/Orchestrator“Complex tasks with clear decomposition, tasks requiring coordination across domains.”任务可清晰分解、需要跨领域协调Peer-to-Peer/Swarm“Tasks requiring flexible exploration, tasks where rigid planning is counterproductive.”需要灵活探索、刚性规划适得其反Hierarchical“Large-scale projects with clear hierarchical structure.”具有清晰层级结构的大型项目选择结论Supervisor/Orchestrator。理由来自映射文档书籍生产具有清晰的顺序阶段scrape → analyze → synthesize → write → edit阶段之间的质量门禁需要中央协调且内容质量需要人工监督点。这与 PRD 中架构图完全对应User Config - Orchestrator - [Scraper, Analyzer, Synthesizer, Writer, Editor] - Daily Book3.3 围绕“电话游戏问题”的设计对冲技能文档指出 supervisor 架构存在固有缺陷监督者会转述子 Agent 的回复每转述一次就损失一层保真度LangGraph 基准测试显示初始 supervisor 架构比优化版本差约 50%。X-to-Book 的应对是双重的文件系统协调Scraper 将原始推文写入文件系统Analyzer 从文件系统读取——大块数据从不穿过 Orchestrator 的上下文对应技能中“使用文件系统记忆而非消息传递保证需要被多个 Agent 忠实访问的状态”的 gotcha 建议摘要化路由Orchestrator 只接收各阶段产出的摘要与质量评分从根上消除转述失真的可能。Orchestrator 的状态结构在 PRD.md 中给出了 TypedDict 定义可见其上下文只承载路由与协调元数据class OrchestratorState(TypedDict): target_accounts: List[str] current_phase: str phase_outputs: Dict[str, Any] quality_scores: Dict[str, float] book_outline: str checkpoints: List[Dict]其中checkpoints字段对应技能中“用 checkpointing 持久化 supervisor 状态避免在上下文中携带完整历史”的失败模式缓解建议。四、context-fundamentals把上下文当作有限资源来预算4.1 概念映射概念技能原文要点PRD 落地上下文是有限资源“Context must be treated as a finite resource with diminishing marginal returns.”每个 Agent 分配显式 token 预算Orchestrator 50k、Writer 80k 等渐进式披露“Progressive disclosure manages context efficiently by loading information only as needed.”先加载书籍大纲仅当 Writer 处理某章时才加载该章内容注意力预算“Models develop attention patterns from training data distributions where shorter sequences predominate.”上下文上限保守地设置在模型最大值之下工具输出体积“Tool outputs comprise the majority of tokens in typical agent trajectories, with research showing observations can reach 83.9% of total context usage.”推文数据单独处理永不进入主 Agent 上下文context-fundamentals 技能 的核心心智模型是上下文不是存储箱而是有限的注意力预算。每个 token 都会竞争模型的注意力而模型的“有效容量”往往显著低于名义窗口——这解释了为何 PRD 中所有预算都刻意低于模型标称上限。4.2 显式上下文预算核心 YAML 配置映射文档完整给出了技能原则“Design with explicit context budgets in mind. Know the effective context limit for your model and task.”在 PRD 中的落地实现context_limits: orchestrator: 50000 # Routing only, no raw data scraper: 20000 # One account at a time analyzer: 80000 # Pattern extraction synthesizer: 100000 # Cross-account synthesis writer: 80000 # Per-chapter drafting editor: 60000 # Per-chapter review这些数值与 PRD 中六个 Agent 的职责一一对应可读性极强Orchestrator50k仅做任务分解、质量门禁与协调不携带原始推文防止监督者瓶颈Scraper20k一次只处理一个账号只做工具调用Analyzer80k处理单个账号的模式提取Synthesizer100k跨账号综合预算最高Writer80k逐章起草Editor60k逐章审校。这里体现的是技能中“按 5–10% 预留缓冲、按类别分配 token 预算并在会话开始前确定”的预算管理建议——每个 Agent 的预算与其角色的信息负载量严格匹配而不是一刀切。4.3 渐进式披露的两级加载PRD 用两级数据结构落实渐进式披露# Level 1: Outline only book_outline { chapters: [ {title: Chapter 1, themes: [AI, Regulation], word_count_target: 2000} ] } # Level 2: Full chapter context (only when writing) chapter_context load_chapter_context(chapter_id)这与技能“先加载摘要任务需要时才获取详情段落”的建议一致同时遵循其边界原则一旦激活就完整加载避免半加载造成的推理缺口。五、memory-systems为什么向量库不够要选时序知识图谱5.1 概念映射概念技能原文要点PRD 落地向量库局限“Vector stores lose relationship information... cannot answer What products did customers who purchased Product Y also buy?”账号间关系查询选择知识图谱而非向量库时间有效性“Temporal knowledge graphs add validity periods to facts. Each fact has a valid from and optionally valid until timestamp.”所有关系都带时间有效性用于追踪立场演化实体记忆“Entity memory specifically tracks information about entities to maintain consistency.”定义 Account、Tweet、Theme、Book、Chapter 五类实体memory-systems 技能 给出了记忆架构选择的决策准则“Choose memory architecture based on requirements: Simple persistence needs → File-system memory; Semantic search needs → Vector RAG; Relationship reasoning needs → Knowledge graph; Temporal validity needs → Temporal knowledge graph.”5.2 需求驱动的架构决策映射文档首先列出了系统必须回答的三类查询“account 在过去 30 天对 AI 说了什么”→ 需要时间 实体过滤“哪些账号在 crypto 上意见相左”→ 需要关系遍历“account 的立场如何演化”→ 需要时序查询这三类查询恰好分别命中了向量库的两个已知缺陷丢失关系信息、无法区分“当前事实”与“过期事实”因此结论Temporal Knowledge Graph时序知识图谱。5.3 实体与关系建模PRD 中的实体类型定义了五类实体及其属性Account、Tweet、Theme、Book、Chapter关系类型则包含POSTED、DISCUSSES带 sentiment/stance 属性、RESPONDS_TO、AGREES_WITH、DISAGREES_WITH带on_theme属性、CONTAINS、SOURCES。其中与时间相关的关系POSTED、DISCUSSES、AGREES_WITH、DISAGREES_WITH都标记为temporal: True正是技能中“为任何会随时间变化的事实追踪有效性区间”的落地。记忆检索模式直接对应三类查询# What has account said about AI in the last 30 days? query_account_theme_temporal(account_id, themeAI, days30) # Which accounts disagree on crypto? query_disagreement_network(themecrypto) # What quotes should be in todays book about regulation? query_quotable_content(themeregulation, min_engagement100)需要补充的边界技能强调“从最浅的记忆层开始检索质量下降时再升级结构”并提醒**“验证但不丢弃”**——保留历史对时序重建至关重要这对应 PRD 配置中memory.retention_days: 90与consolidation_frequency: weekly的设计意图详见 PRD.md 的配置段。六、context-optimization对抗每日 10 万 token 的推文洪流6.1 挑战规模PRD 给出了量级估算单账号 20 条推文/天 × 10 个账号 200 条/天每条带线程上下文约 500 token每日原始上下文约 10 万 token。这正是 context-optimization 技能 中“工具输出在 agent 轨迹中占 80% token”论断的极端案例。6.2 四项优化技术的映射落地技术技能要点PRD 落地观察掩蔽“Observation masking replaces verbose tool outputs with compact references.”原始推文数据写入文件系统不进入任何 Agent 上下文压缩触发“Trigger compaction after significant memory accumulation, when retrieval returns too many outdated results.”上下文利用率达 70% 时触发压缩KV-cache 优化“Place stable elements first (system prompt, tool definitions), then frequently reused elements, then unique elements last.”上下文排序系统提示 → 工具 → 账号配置 → 每日大纲 → 当前任务渐进式披露与 context-fundamentals 共用大纲先行、章节内容按需加载掩蔽管线映射文档完整给出Scraper 写入文件系统 → Analyzer 从文件系统读取并产出摘要 →只有摘要流入后续阶段。10 万 token 的原始数据在进入 Synthesizer 之前已经被压缩为结构化分析结果。压缩阈值代码映射文档原文COMPACTION_THRESHOLD 0.7 # 70% context utilization if context_utilization COMPACTION_THRESHOLD: phase_outputs compact_phase_outputs(phase_outputs)对照技能建议压缩目标为 50–70% token 缩减、质量损失 5%且压缩发生在掩蔽之后先移除低价值主体再总结剩余内容。同时技能警告压缩应触发在 70–80% 而非 90%——在自身压力过大的模型上执行压缩会丢失关键状态X-to-Book 的 0.7 阈值正落在技能推荐的区间。KV-cache 排序PRD 将上下文组织为system_prompt → tool_definitions → account_config → daily_outline → current_task即“稳定元素在前、每日变化居中、单次调用独有的放最后”。技能强调前缀中哪怕一个空白字符变化都会使缓存块整体失效因此系统提示与工具定义被固定为不可变字符串。七、tool-design3 个合并工具替代 15 窄工具7.1 概念映射概念技能原文要点PRD 落地合并原则“If a human engineer cannot definitively say which tool should be used in a given situation, an agent cannot be expected to do better.”3 个合并工具替代 15 窄工具描述结构“Effective tool descriptions answer four questions: What does the tool do? When should it be used? What inputs does it accept? What does it return?”所有工具带显式使用触发条件与错误恢复指引响应格式选项“Implementing response format options gives agents control over verbosity.”工具支持 “concise” 与 “detailed” 两种格式参数错误消息设计“Error messages must be actionable. They must tell the agent what went wrong and how to correct it.”错误含恢复指引如RATE_LIMITED返回retry_aftertool-design 技能 的合并原则原文给出示例“Instead of implementing list_users, list_events, and create_event, implement schedule_event that handles the full workflow internally.”——把完整工作流封装进单一工具消除 Agent 按正确顺序链式调用的负担。7.2 合并前后对照映射文档完整记录了被规避的窄工具清单与合并后的最终工具集合并前已规避的 15 窄工具fetch_timeline、fetch_thread、fetch_engagement、search_tweetsstore_entity、query_entities、update_validity等等合并后3 个领域级工具x_data_tool— 所有 X 数据操作memory_tool— 所有知识图谱操作writing_tool— 所有内容操作7.3 工具契约示例以x_data_tool为例PRD.md 中有完整签名它用action参数fetch_timeline/fetch_thread/fetch_engagement/search统一入口提供format: Literal[concise, detailed]控制返回体积并在 docstring 中完整回答“何时使用 / 各 action 语义 / 返回内容 / 错误恢复”四问def x_data_tool( action: Literal[fetch_timeline, fetch_thread, fetch_engagement, search], account_id: Optional[str] None, tweet_id: Optional[str] None, query: Optional[str] None, since_date: Optional[str] None, until_date: Optional[str] None, format: Literal[concise, detailed] concise ) - Dict: ...错误恢复设计尤其值得借鉴RATE_LIMITED错误携带retry_after告诉 Agent 等多久重试、ACCOUNT_PRIVATE、NOT_FOUND均给出明确纠正路径——这正是技能“错误消息必须可执行”原则的体现也是合并后memory_tool中update_validity与consolidateaction 存在的原因合并重复事实、标记事实过期。八、evaluation五维加权质量门禁8.1 概念映射概念技能原文要点PRD 落地多维评分卡“Agent quality is not a single dimension. It includes factual accuracy, completeness, coherence, tool efficiency, and process quality.”5 个加权维度Source Accuracy、Thematic Coherence、Completeness、Insight Quality、ReadabilityLLM-as-judge“LLM-based evaluation scales to large test sets and provides consistent judgments.”对连贯性与洞察质量做自动化评估人工评估“Human evaluation catches what automation misses.”评分 0.7 或 Source Accuracy 0.8 时触发人工评审结果导向评估“The solution is outcome-focused evaluation that judges whether agents achieve right outcomes while following reasonable processes.”评估最终书籍质量而非中间步骤evaluation 技能 强调“用多维评分卡而非单一分数”因为一个数字会掩盖特定维度的关键失败。8.2 评分卡定义映射文档给出了完整的五维加权表维度权重度量方式Source Accuracy来源准确性30%对照原始推文的自动化引文核验Thematic Coherence主题连贯性25%LLM-as-judge 评估叙事流Completeness完整性20%主题覆盖率计算Insight Quality洞察质量15%LLM-as-judge 评估是否超越复述Readability可读性10%自动化指标 LLM judgePRD 进一步给出每个维度的 Excellent / Acceptable / Failed 行为级描述如 Source Accuracy 的 Failed 级为“Fabricated quotes”以及自动化评估管线的伪代码骨架evaluate_daily_book()——按维度分别打分、按权重求加权平均、以overall 0.7判定通过并输出flagged_issues。8.3 人工评审触发条件总分 0.7来源准确率 0.8检测到任何虚构引文新增账号首本书必须评审检测到争议性话题这正对应技能中“人工评估捕捉自动化遗漏的问题”以及“路由边缘案例、异常查询和随机生产流量样本给人工评审”的建议。九、跨技能集成技能库的核心价值主张映射文档末尾用集成矩阵点明这套技能库的真正价值在于互补模式的协同工作。集成点组合技能应用Agent 上下文预算multi-agent-patterns context-fundamentals每个 Agent 依据角色设定显式上限文件系统协调multi-agent-patterns context-optimization避免上下文传递使掩蔽成为可能记忆感知的综合memory-systems context-optimization只查询相关事实不加载完整历史质量驱动的路由evaluation multi-agent-patternsOrchestrator 用质量分做阶段门禁这四个集成点覆盖了系统的四条生命线预算约束每个 Agent 的上下文体量文件系统让大规模数据绕过上下文记忆层让长期知识按需注入质量分驱动流程推进。例如“质量驱动的路由”直接对应 PRD 中 Orchestrator 的quality_scores字段与“评分通过才进入下一阶段”的设计体现了 multi-agent-patterns 与 evaluation 的衔接。十、把映射方法论复用到新项目examples/x-to-book-system/README.md 给出了将本示例复用到新项目的五步法与 SKILLS-MAPPING.md 的映射结构完全同构识别上下文挑战哪些环节存在体积约束什么导致上下文饱和选择架构模式根据协调需求在 supervisor、swarm、hierarchical 之间选择设计记忆系统根据查询模式在向量库、知识图谱、时序图谱之间选择应用优化技术按需使用观察掩蔽、压缩、渐进式披露构建评估框架定义与用例相关的质量维度与权重。这也正是本文的实用价值所在先读技能原则再按“概念 → 决策 → 落地代码”的结构逐条映射最后用集成矩阵检查模式间的协同——你得到的不仅是一个系统的设计文档更是一套可复制的上下文工程决策方法论。延伸阅读仓库内路径技能映射文档——本文主体六技能对照表与跨技能集成矩阵X-to-Book 系统 PRD——架构、实体关系、工具签名、评估管线与完整配置 YAML示例 README——问题背景、技能应用推理过程与复用指南六个技能本体multi-agent-patterns、context-fundamentals、memory-systems、context-optimization、tool-design、evaluation技能参考文档multi-agent-patterns 框架参考含 LangGraph Supervisor 实现、context-components 参考系统提示工程与指令高度校准、memory 实现参考、优化技术参考、tool-design 最佳实践【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Agent Skills 到 X-to-Book 系统的技能映射实战：用 Context Engineering 设计多智能体内容生产线
Agent Skills 到 X-to-Book 系统的技能映射实战用 Context Engineering 设计多智能体内容生产线【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering导读本文深入解析examples/x-to-book-system/SKILLS-MAPPING.md——一份将 Agent Skills for Context Engineering 仓库中的六个核心技能multi-agent-patterns、context-fundamentals、memory-systems、context-optimization、tool-design、evaluation逐一映射到 X-to-Book 多智能体系统设计决策的对照文档。该示例系统用于每日监控指定 XTwitter账号、合成其内容并生成结构化书籍。读完本文你将掌握如何基于技能原则做多智能体架构选型、为每个 Agent 分配显式上下文预算、选择时序知识图谱作为记忆层、用观察掩蔽与压缩对抗 10 万级 token 的社交媒体数据洪流、按合并原则收敛工具集以及用五维加权评分卡做质量门禁。一、文档定位技能库与产品需求之间的“翻译层”SKILLS-MAPPING.md 是整个示例的核心“接线图”。它解决一个实际问题技能仓库提供了大量 context engineering 的模式与原则但每个模式在具体项目中该不该用、用在哪个决策点上需要一份显式的对照表来约束。文档以“技能 → 概念 → PRD 落地”三列结构组织把六条技能分别映射到 X-to-Book 系统 PRD 的具体设计决策上并在末尾给出跨技能集成矩阵说明这些模式如何协同工作。该示例的完整背景与使用方式见 examples/x-to-book-system/README.md其核心定位是把技能库当作“词汇与模式”把具体项目当作“约束下的应用”。二、技能映射总览SKILLS-MAPPING.md 覆盖了 6 项技能每项对应系统中的一个核心设计决策技能Skill对应核心决策multi-agent-patterns选择 Supervisor/Orchestrator 架构 文件系统协调context-fundamentals按角色分配显式 token 预算 渐进式披露memory-systems选择时序知识图谱Temporal Knowledge Graphcontext-optimization观察掩蔽 70% 压缩触发 KV-cache 排序tool-design3 个合并工具替代 15 窄工具evaluation五维加权评分 自动/人工评估流水线下面逐一展开每条映射都补充了技能原文的原理依据与 PRD 中的落地代码。三、multi-agent-patterns为什么选 Supervisor/Orchestrator3.1 概念映射概念技能原文要点PRD 落地Supervisor 模式“supervisor pattern places a central agent in control, delegating to specialists and synthesizing results.”Orchestrator 协调 Scraper、Analyzer、Synthesizer、Writer、Editor 五个专家 Agent上下文隔离“Sub-agents exist primarily to isolate context, not to anthropomorphize role division.”每个 Agent 在聚焦自身阶段的干净上下文中运行电话游戏问题“LangGraph benchmarks found supervisor architectures initially performed 50% worse due to the telephone game problem where supervisors paraphrase sub-agent responses incorrectly.”各阶段输出写入文件系统而非经由 Orchestrator 转述合成文件系统协调“For complex tasks requiring shared state, agents read and write to persistent storage.”所有 Agent 间数据流经文件系统监督者瓶颈缓解“Implement output schema constraints so workers return only distilled summaries.”Orchestrator 只接收阶段摘要绝不接收原始数据关键洞察来自 skills/multi-agent-patterns/SKILL.md多智能体架构的首要收益是上下文隔离而不是“拟人化地分工”。X-to-Book 的场景正好符合该技能的激活条件——单 Agent 上下文无法容纳高量社交媒体数据、任务可自然分解为顺序阶段、各阶段需要不同的工具集与系统提示词。3.2 三种模式的选择逻辑multi-agent-patterns 技能 描述了三种主导模式映射文档完整记录了每种模式“何时使用”的判定Supervisor/Orchestrator“Complex tasks with clear decomposition, tasks requiring coordination across domains.”任务可清晰分解、需要跨领域协调Peer-to-Peer/Swarm“Tasks requiring flexible exploration, tasks where rigid planning is counterproductive.”需要灵活探索、刚性规划适得其反Hierarchical“Large-scale projects with clear hierarchical structure.”具有清晰层级结构的大型项目选择结论Supervisor/Orchestrator。理由来自映射文档书籍生产具有清晰的顺序阶段scrape → analyze → synthesize → write → edit阶段之间的质量门禁需要中央协调且内容质量需要人工监督点。这与 PRD 中架构图完全对应User Config - Orchestrator - [Scraper, Analyzer, Synthesizer, Writer, Editor] - Daily Book3.3 围绕“电话游戏问题”的设计对冲技能文档指出 supervisor 架构存在固有缺陷监督者会转述子 Agent 的回复每转述一次就损失一层保真度LangGraph 基准测试显示初始 supervisor 架构比优化版本差约 50%。X-to-Book 的应对是双重的文件系统协调Scraper 将原始推文写入文件系统Analyzer 从文件系统读取——大块数据从不穿过 Orchestrator 的上下文对应技能中“使用文件系统记忆而非消息传递保证需要被多个 Agent 忠实访问的状态”的 gotcha 建议摘要化路由Orchestrator 只接收各阶段产出的摘要与质量评分从根上消除转述失真的可能。Orchestrator 的状态结构在 PRD.md 中给出了 TypedDict 定义可见其上下文只承载路由与协调元数据class OrchestratorState(TypedDict): target_accounts: List[str] current_phase: str phase_outputs: Dict[str, Any] quality_scores: Dict[str, float] book_outline: str checkpoints: List[Dict]其中checkpoints字段对应技能中“用 checkpointing 持久化 supervisor 状态避免在上下文中携带完整历史”的失败模式缓解建议。四、context-fundamentals把上下文当作有限资源来预算4.1 概念映射概念技能原文要点PRD 落地上下文是有限资源“Context must be treated as a finite resource with diminishing marginal returns.”每个 Agent 分配显式 token 预算Orchestrator 50k、Writer 80k 等渐进式披露“Progressive disclosure manages context efficiently by loading information only as needed.”先加载书籍大纲仅当 Writer 处理某章时才加载该章内容注意力预算“Models develop attention patterns from training data distributions where shorter sequences predominate.”上下文上限保守地设置在模型最大值之下工具输出体积“Tool outputs comprise the majority of tokens in typical agent trajectories, with research showing observations can reach 83.9% of total context usage.”推文数据单独处理永不进入主 Agent 上下文context-fundamentals 技能 的核心心智模型是上下文不是存储箱而是有限的注意力预算。每个 token 都会竞争模型的注意力而模型的“有效容量”往往显著低于名义窗口——这解释了为何 PRD 中所有预算都刻意低于模型标称上限。4.2 显式上下文预算核心 YAML 配置映射文档完整给出了技能原则“Design with explicit context budgets in mind. Know the effective context limit for your model and task.”在 PRD 中的落地实现context_limits: orchestrator: 50000 # Routing only, no raw data scraper: 20000 # One account at a time analyzer: 80000 # Pattern extraction synthesizer: 100000 # Cross-account synthesis writer: 80000 # Per-chapter drafting editor: 60000 # Per-chapter review这些数值与 PRD 中六个 Agent 的职责一一对应可读性极强Orchestrator50k仅做任务分解、质量门禁与协调不携带原始推文防止监督者瓶颈Scraper20k一次只处理一个账号只做工具调用Analyzer80k处理单个账号的模式提取Synthesizer100k跨账号综合预算最高Writer80k逐章起草Editor60k逐章审校。这里体现的是技能中“按 5–10% 预留缓冲、按类别分配 token 预算并在会话开始前确定”的预算管理建议——每个 Agent 的预算与其角色的信息负载量严格匹配而不是一刀切。4.3 渐进式披露的两级加载PRD 用两级数据结构落实渐进式披露# Level 1: Outline only book_outline { chapters: [ {title: Chapter 1, themes: [AI, Regulation], word_count_target: 2000} ] } # Level 2: Full chapter context (only when writing) chapter_context load_chapter_context(chapter_id)这与技能“先加载摘要任务需要时才获取详情段落”的建议一致同时遵循其边界原则一旦激活就完整加载避免半加载造成的推理缺口。五、memory-systems为什么向量库不够要选时序知识图谱5.1 概念映射概念技能原文要点PRD 落地向量库局限“Vector stores lose relationship information... cannot answer What products did customers who purchased Product Y also buy?”账号间关系查询选择知识图谱而非向量库时间有效性“Temporal knowledge graphs add validity periods to facts. Each fact has a valid from and optionally valid until timestamp.”所有关系都带时间有效性用于追踪立场演化实体记忆“Entity memory specifically tracks information about entities to maintain consistency.”定义 Account、Tweet、Theme、Book、Chapter 五类实体memory-systems 技能 给出了记忆架构选择的决策准则“Choose memory architecture based on requirements: Simple persistence needs → File-system memory; Semantic search needs → Vector RAG; Relationship reasoning needs → Knowledge graph; Temporal validity needs → Temporal knowledge graph.”5.2 需求驱动的架构决策映射文档首先列出了系统必须回答的三类查询“account 在过去 30 天对 AI 说了什么”→ 需要时间 实体过滤“哪些账号在 crypto 上意见相左”→ 需要关系遍历“account 的立场如何演化”→ 需要时序查询这三类查询恰好分别命中了向量库的两个已知缺陷丢失关系信息、无法区分“当前事实”与“过期事实”因此结论Temporal Knowledge Graph时序知识图谱。5.3 实体与关系建模PRD 中的实体类型定义了五类实体及其属性Account、Tweet、Theme、Book、Chapter关系类型则包含POSTED、DISCUSSES带 sentiment/stance 属性、RESPONDS_TO、AGREES_WITH、DISAGREES_WITH带on_theme属性、CONTAINS、SOURCES。其中与时间相关的关系POSTED、DISCUSSES、AGREES_WITH、DISAGREES_WITH都标记为temporal: True正是技能中“为任何会随时间变化的事实追踪有效性区间”的落地。记忆检索模式直接对应三类查询# What has account said about AI in the last 30 days? query_account_theme_temporal(account_id, themeAI, days30) # Which accounts disagree on crypto? query_disagreement_network(themecrypto) # What quotes should be in todays book about regulation? query_quotable_content(themeregulation, min_engagement100)需要补充的边界技能强调“从最浅的记忆层开始检索质量下降时再升级结构”并提醒**“验证但不丢弃”**——保留历史对时序重建至关重要这对应 PRD 配置中memory.retention_days: 90与consolidation_frequency: weekly的设计意图详见 PRD.md 的配置段。六、context-optimization对抗每日 10 万 token 的推文洪流6.1 挑战规模PRD 给出了量级估算单账号 20 条推文/天 × 10 个账号 200 条/天每条带线程上下文约 500 token每日原始上下文约 10 万 token。这正是 context-optimization 技能 中“工具输出在 agent 轨迹中占 80% token”论断的极端案例。6.2 四项优化技术的映射落地技术技能要点PRD 落地观察掩蔽“Observation masking replaces verbose tool outputs with compact references.”原始推文数据写入文件系统不进入任何 Agent 上下文压缩触发“Trigger compaction after significant memory accumulation, when retrieval returns too many outdated results.”上下文利用率达 70% 时触发压缩KV-cache 优化“Place stable elements first (system prompt, tool definitions), then frequently reused elements, then unique elements last.”上下文排序系统提示 → 工具 → 账号配置 → 每日大纲 → 当前任务渐进式披露与 context-fundamentals 共用大纲先行、章节内容按需加载掩蔽管线映射文档完整给出Scraper 写入文件系统 → Analyzer 从文件系统读取并产出摘要 →只有摘要流入后续阶段。10 万 token 的原始数据在进入 Synthesizer 之前已经被压缩为结构化分析结果。压缩阈值代码映射文档原文COMPACTION_THRESHOLD 0.7 # 70% context utilization if context_utilization COMPACTION_THRESHOLD: phase_outputs compact_phase_outputs(phase_outputs)对照技能建议压缩目标为 50–70% token 缩减、质量损失 5%且压缩发生在掩蔽之后先移除低价值主体再总结剩余内容。同时技能警告压缩应触发在 70–80% 而非 90%——在自身压力过大的模型上执行压缩会丢失关键状态X-to-Book 的 0.7 阈值正落在技能推荐的区间。KV-cache 排序PRD 将上下文组织为system_prompt → tool_definitions → account_config → daily_outline → current_task即“稳定元素在前、每日变化居中、单次调用独有的放最后”。技能强调前缀中哪怕一个空白字符变化都会使缓存块整体失效因此系统提示与工具定义被固定为不可变字符串。七、tool-design3 个合并工具替代 15 窄工具7.1 概念映射概念技能原文要点PRD 落地合并原则“If a human engineer cannot definitively say which tool should be used in a given situation, an agent cannot be expected to do better.”3 个合并工具替代 15 窄工具描述结构“Effective tool descriptions answer four questions: What does the tool do? When should it be used? What inputs does it accept? What does it return?”所有工具带显式使用触发条件与错误恢复指引响应格式选项“Implementing response format options gives agents control over verbosity.”工具支持 “concise” 与 “detailed” 两种格式参数错误消息设计“Error messages must be actionable. They must tell the agent what went wrong and how to correct it.”错误含恢复指引如RATE_LIMITED返回retry_aftertool-design 技能 的合并原则原文给出示例“Instead of implementing list_users, list_events, and create_event, implement schedule_event that handles the full workflow internally.”——把完整工作流封装进单一工具消除 Agent 按正确顺序链式调用的负担。7.2 合并前后对照映射文档完整记录了被规避的窄工具清单与合并后的最终工具集合并前已规避的 15 窄工具fetch_timeline、fetch_thread、fetch_engagement、search_tweetsstore_entity、query_entities、update_validity等等合并后3 个领域级工具x_data_tool— 所有 X 数据操作memory_tool— 所有知识图谱操作writing_tool— 所有内容操作7.3 工具契约示例以x_data_tool为例PRD.md 中有完整签名它用action参数fetch_timeline/fetch_thread/fetch_engagement/search统一入口提供format: Literal[concise, detailed]控制返回体积并在 docstring 中完整回答“何时使用 / 各 action 语义 / 返回内容 / 错误恢复”四问def x_data_tool( action: Literal[fetch_timeline, fetch_thread, fetch_engagement, search], account_id: Optional[str] None, tweet_id: Optional[str] None, query: Optional[str] None, since_date: Optional[str] None, until_date: Optional[str] None, format: Literal[concise, detailed] concise ) - Dict: ...错误恢复设计尤其值得借鉴RATE_LIMITED错误携带retry_after告诉 Agent 等多久重试、ACCOUNT_PRIVATE、NOT_FOUND均给出明确纠正路径——这正是技能“错误消息必须可执行”原则的体现也是合并后memory_tool中update_validity与consolidateaction 存在的原因合并重复事实、标记事实过期。八、evaluation五维加权质量门禁8.1 概念映射概念技能原文要点PRD 落地多维评分卡“Agent quality is not a single dimension. It includes factual accuracy, completeness, coherence, tool efficiency, and process quality.”5 个加权维度Source Accuracy、Thematic Coherence、Completeness、Insight Quality、ReadabilityLLM-as-judge“LLM-based evaluation scales to large test sets and provides consistent judgments.”对连贯性与洞察质量做自动化评估人工评估“Human evaluation catches what automation misses.”评分 0.7 或 Source Accuracy 0.8 时触发人工评审结果导向评估“The solution is outcome-focused evaluation that judges whether agents achieve right outcomes while following reasonable processes.”评估最终书籍质量而非中间步骤evaluation 技能 强调“用多维评分卡而非单一分数”因为一个数字会掩盖特定维度的关键失败。8.2 评分卡定义映射文档给出了完整的五维加权表维度权重度量方式Source Accuracy来源准确性30%对照原始推文的自动化引文核验Thematic Coherence主题连贯性25%LLM-as-judge 评估叙事流Completeness完整性20%主题覆盖率计算Insight Quality洞察质量15%LLM-as-judge 评估是否超越复述Readability可读性10%自动化指标 LLM judgePRD 进一步给出每个维度的 Excellent / Acceptable / Failed 行为级描述如 Source Accuracy 的 Failed 级为“Fabricated quotes”以及自动化评估管线的伪代码骨架evaluate_daily_book()——按维度分别打分、按权重求加权平均、以overall 0.7判定通过并输出flagged_issues。8.3 人工评审触发条件总分 0.7来源准确率 0.8检测到任何虚构引文新增账号首本书必须评审检测到争议性话题这正对应技能中“人工评估捕捉自动化遗漏的问题”以及“路由边缘案例、异常查询和随机生产流量样本给人工评审”的建议。九、跨技能集成技能库的核心价值主张映射文档末尾用集成矩阵点明这套技能库的真正价值在于互补模式的协同工作。集成点组合技能应用Agent 上下文预算multi-agent-patterns context-fundamentals每个 Agent 依据角色设定显式上限文件系统协调multi-agent-patterns context-optimization避免上下文传递使掩蔽成为可能记忆感知的综合memory-systems context-optimization只查询相关事实不加载完整历史质量驱动的路由evaluation multi-agent-patternsOrchestrator 用质量分做阶段门禁这四个集成点覆盖了系统的四条生命线预算约束每个 Agent 的上下文体量文件系统让大规模数据绕过上下文记忆层让长期知识按需注入质量分驱动流程推进。例如“质量驱动的路由”直接对应 PRD 中 Orchestrator 的quality_scores字段与“评分通过才进入下一阶段”的设计体现了 multi-agent-patterns 与 evaluation 的衔接。十、把映射方法论复用到新项目examples/x-to-book-system/README.md 给出了将本示例复用到新项目的五步法与 SKILLS-MAPPING.md 的映射结构完全同构识别上下文挑战哪些环节存在体积约束什么导致上下文饱和选择架构模式根据协调需求在 supervisor、swarm、hierarchical 之间选择设计记忆系统根据查询模式在向量库、知识图谱、时序图谱之间选择应用优化技术按需使用观察掩蔽、压缩、渐进式披露构建评估框架定义与用例相关的质量维度与权重。这也正是本文的实用价值所在先读技能原则再按“概念 → 决策 → 落地代码”的结构逐条映射最后用集成矩阵检查模式间的协同——你得到的不仅是一个系统的设计文档更是一套可复制的上下文工程决策方法论。延伸阅读仓库内路径技能映射文档——本文主体六技能对照表与跨技能集成矩阵X-to-Book 系统 PRD——架构、实体关系、工具签名、评估管线与完整配置 YAML示例 README——问题背景、技能应用推理过程与复用指南六个技能本体multi-agent-patterns、context-fundamentals、memory-systems、context-optimization、tool-design、evaluation技能参考文档multi-agent-patterns 框架参考含 LangGraph Supervisor 实现、context-components 参考系统提示工程与指令高度校准、memory 实现参考、优化技术参考、tool-design 最佳实践【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考