Context Engineering

wiki/ai/concepts/Context-Engineering.md

分类：ai / concepts · 更新：2026-09-11 09:14 最近更新

Context Engineering（上下文工程）

回读与信任边界： [[arc-addressable-recall-context-compaction

ARC]] 区分外部原文存储、有界工作视图与地址发现，不能把可恢复性当任务成功；[[spa-plan-first-label-preserving-persistent-agents

SPA]] 则要求跨查询取回时保留机密性/完整性标签，摘要不提升信任。二者分别解决“能否找回”与“取回后允许怎么用”；评测还要区分 producer 成功、条件召回和端到端完成。^[raw/articles/arc-addressable-recall-context-compaction-2026-09-11.md] ^[raw/articles/spa-plan-first-label-preserving-persistent-agents-2026-09-11.md]

定义

系统性提升 AI 可消费上下文质量的工程实践。不是每次手动补 prompt，而是建立一次投入、持续生效的上下文基建。

核心公式

代码产出 = AI 能力 × 上下文质量

上下文质量是比模型能力更高效的杠杆，因为它完全掌握在团队手中。

五类上下文缺口

隐性规范 — 团队约定但未文档化的规则
历史决策 — 为什么选了A不选B
服务契约 — IDL 字段冻结状态、下游依赖
跨服务依赖 — 同一需求涉及的服务拓扑
演进轨迹 — 上次大改的坑和灰度策略

QQ音乐的三层知识体系

团队级 context/team/（所有项目遵循）
框架工程级 context/harness-framework/（所有需求研发遵循）
服务级 context/project/{project}/{module}/（特定服务）

与 LLM-Wiki 的关系

LLM Wiki 是个人层面的 Context Engineering——把知识编译一次、持续复用。QQ音乐的实践是企业级版本——团队层面的上下文工程。

2026-06-30 补充：AGENTS.md 作为仓库级上下文

AGENTS.md-Context-Files 代表一种轻量仓库级上下文标准：把 setup、测试、代码风格、约束和验证门禁放在 coding agents 可预测读取的位置。它符合 Context Engineering 的基本思想：把隐性规则变成版本化、可复用、可审查的上下文资产。

但 [[agents-md-context-files-paper Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?]] 提醒：context file 的效果需要实证评估。一个过长、过期或泛化的 AGENTS.md 可能只是在增加噪音。好的做法是短、准、可验证，并链接到更深的 wiki/spec/skill，而不是把所有知识塞进一个文件。

2026-07-02 补充：上下文工程的插件化

[[context-engineering-kit

Context Engineering Kit]] 展示了上下文工程从“写一份长规则”走向“按需加载插件”的趋势。关键不是 skills 数量，而是 token-efficient、granular、quality-focused：每个 plugin 只在相关任务中加载对应 agents、commands、skills，避免把无关知识常驻上下文。

这补充了本页的定义：Context Engineering 不只是整理上下文内容，也包括上下文的加载策略、粒度边界、标准化格式和反思/记忆闭环。对 Hermes 来说，好的 skill 应该像小型 workflow package：触发条件清晰、引用深入资料、可验证、可卸载，而不是一段泛化 prompt。

2026-07-03 补充：上下文应分为确定性结构、经验 playbook 与来源证据

[[enola-deterministic-codebase-architecture-graph

Enola]] 和 ACE/自学习 playbook 类项目共同提示：Context Engineering 不应只有一类“长文档”。更稳的分层是：确定性结构图负责代码事实；经验 playbook 负责可编辑策略；raw/source/wiki 负责来源证据；eval/harness 负责验证。

对 Hermes 来说，这意味着 skill 不应把所有上下文塞进 prompt，而应声明自己需要哪类上下文 provider：wiki 语义检索、仓库结构图、命令输出、用户偏好、历史决策或安全边界。

2026-07-04 补充：上下文层要测 adoption、determinism 与 token efficiency

[[agent-context-workshop

Agent Context Workshop]] 把 Context Engineering 进一步具体化为可实验的上下文 provider：同一组代码问题下，graph agent 与 grep agent 的单次准确率差距不大，但 graph 在重复运行确定性、关系问题稳定性、token efficiency 和 tool adoption 上更有价值。

这对本页定义很关键：上下文工程不是“准备了很多上下文”就结束，而是要回答三件事：agent 是否真的采用了该上下文；采用后是否减少重复推理和 token；多次运行是否更稳定。对 Hermes / llm-wiki 来说，wiki-vquery、wikilinks、raw provenance 和 index/log 都应被视为 context provider，并在任务报告里留下使用证据。

2026-07-06 补充：上下文治理层

[[contextnest-verifiable-context-governance

ContextNest / ContextNext]] 提醒：检索相关性不是上下文工程的全部。Agent 使用知识库前，还需要判断材料是否被批准、是否当前有效、版本和 hash 是否可追踪、输出到底消费了哪一版上下文。

对 llm-wiki 来说，这把 raw sha256、index/log、category selector、vector index 范围和 query evidence 都提升为治理对象。下一步不一定是重型企业系统，而是轻量 context manifest：记录一次重要回答或 ingest 实际使用了哪些页面、版本/mtime/hash 是什么、是否来自允许范围。

2026-07-07 补充：持久记忆要能证明自己减少重复探索

[[greplica-persistent-coding-agent-memory

Greplica]] 把 persistent repository memory 变成了可评测的 context provider：用 prior sessions 构建记忆，在未来 held-out session 的 planning task 上比较 baseline 与 memory arm，并衡量 plan quality、tokens、tool calls、时间和成本。

这对 Context Engineering 的定义很关键：上下文系统不是“资料越多越好”，而是要在任务开始时提供最小高信号历史，减少重复 grep/read/探索，并能通过对照实验证明自己 load-bearing。对 llm-wiki 来说，_index、wikilinks、raw provenance、wiki-vquery 和 ConversationSpec 也应该接受类似评估：是否真的帮助新 session 更快定位证据、减少重复搜索、降低幻觉。

2026-07-10 补充：workflow/context snapshot 也应成为知识对象

[[workflow-as-knowledge-semantic-persistence

Workflow as Knowledge]] 把 context engineering 的边界从“提供材料给模型”扩展到“记录 workflow 使用了哪些上下文、哪些步骤是确定性 derive、哪些步骤是 LLM infer”。对长期知识库而言，缺少 context snapshot 的回答很难复盘：即使结论正确，也不知道它消费了哪些页面、raw、搜索结果和工具证据。

这对 llm-wiki 的直接启发是：重要 ingest/query 不应只更新最终 page，还应在 log 或优化文章中留下最小 context manifest。hash、文件存在、wikilink 检查、向量重建是 derive；深度判断、概念综合、晋升/拒绝理由是 infer。把二者分开记录，能让未来的 Harness-Engineering 更容易验证、恢复和演化。

2026-07-11 补充：上下文压缩是 rate-distortion 决策

[[memory-compaction-rate-distortion-agents

What to Keep, What to Forget]] 把 KV cache、prompt pruning、architectural state 和 agent long-term memory 统一为 rate-distortion 问题：在预算下保留哪些上下文衍生信息、以什么保真度保留，以最小化未来任务损失。

这对 Context Engineering 很关键：上下文系统的目标不是“记得更多”，而是用有限 token/latency/storage/维护成本保留对未来任务最有用、最可追溯、最可恢复的信息。对 llm-wiki 而言，raw/source/concept/index/log/vector index 是不同保真度的 memory layers；每日雷达的“只深挖少数高价值材料”就是一种有意识的 compaction policy。

2026-07-12 补充：工具/技能 schema 也是上下文预算

[[ratel-context-engineering-tool-selection

Ratel]] 提醒：Context Engineering 不只管理文档、wiki 和 long-term memory，也管理工具与 skill schema 的加载。随着 agent 可用工具变多，全量注入会带来 token 成本、工具混淆和选择错误；更稳的做法是把能力放进 catalog，每轮只检索并暴露相关工具。

对 llm-wiki / Hermes 来说，skill 应逐步从“长 prompt 文档”升级为可索引 manifest：触发条件、输入输出、风险等级、验证方式、相关 wiki 页面。wiki-vquery 也可以从内容检索扩展到 capability retrieval，帮助 agent 决定下一步该加载哪个 skill 或工具。

2026-07-14 补充：仓库上下文需要可路由边界，而不是更长说明书

[[aigx-context-format AIGX]] 把仓库上下文组织成 .aigx/ genome 与 per-file boundary index，强调规则、禁止导入、gotchas 和模块边界应可被工具定位，而不是堆在一份长文档里。这补充了 AGENTS.md-Context-Files 的线性上下文模式：AGENTS.md 适合入口说明，AIGX 类结构更适合细粒度路由。

[[seta-scaling-environments-terminal-agents

SETA]] 和 [[execute-code-tool-surface-ablation

execute_code 工具面限制实验]] 也提示：上下文质量必须和任务环境、工具面一起评估。一个 context format 如果只在某种 harness/tool surface 下有效，就不能被当成通用改进。对 llm-wiki 来说，下一步可考虑给重要页面/skill 增加轻量 manifest：触发条件、边界、验证方式、相关页面。

2026-07-15 补充：上下文应由知识缺口驱动，而不只是关键词检索

[[acquire-qa-driven-repository-knowledge

ACQUIRE]] 把 coding-agent 的仓库理解显式拆成 question-driven knowledge acquisition：先问机制/行为、设计/用法、位置/结构、生态/标准四类问题，再用只读探索形成 evidence-grounded QA，最后才进入修复。它补充了本页的核心定义：Context Engineering 不只是“给 agent 更多上下文”，而是让每段上下文回答一个明确知识缺口。

对 llm-wiki 来说，这可以转化为 deep ingest 的前置合同：正式写页面前，先确认材料回答了什么机制问题、补充了哪个已有概念、证据来自哪里、哪些问题仍未回答。否则，检索命中和摘要流畅都可能只是低信号上下文。

2026-07-18 补充：上下文质量应作为独立 preflight 指标

[[context-fails-first

AI Agents Do Not Fail Alone]] 把 context quality 拆成七个可评分维度：role clarity、guardrail coverage、instruction consistency、tool schema quality、grounding sufficiency、injection hardening、token efficiency。它的价值在于把上下文质量从事后解释变成独立 leading indicator：先评价运行环境，再评价行为结果。

对 llm-wiki 来说，这可以转成页面/skill/cron prompt 的轻量 preflight：是否说明适用角色与边界，是否有足够来源和 wikilinks，工具 schema 是否清楚，是否避免把未验证/不可信材料混进执行上下文，是否控制 token footprint。

2026-07-19 补充：长期 wiki 需要任务级 Purpose Bundle

[[okfy-purpose-shaped-knowledge-bundles

OKFy]] 把 Context Engineering 的一个关键张力讲清楚：长期知识库为了 compounding 会不断变大，但具体任务需要的是按 Purpose 裁剪后的高信号工作集。上下文工程因此不只是检索 top-k，而是先定义“本次知识服务什么决策/任务”，再把相关概念、当前状态、已废弃内容、矛盾和来源证据压缩成 agent 可消费的 bundle。

对 llm-wiki 来说，_index.md、wikilinks 和 wiki-vquery 是发现层；正式回答或复杂 ingest 还应形成轻量 context manifest：本次使用了哪些页面/原始来源，哪些结论来自 deterministic check，哪些来自 LLM synthesis，哪些材料因过期/低相关被排除。这样可以减少 attention dilution，也让未来的 Harness-Engineering 更容易复盘。

2026-07-21 补充：上下文应通过只读委托与 fresh-context worker 控制噪音

[[fastcontext-read-only-repository-exploration

FastContext]] 提供了一个窄而实用的上下文模式：主 coding agent 不直接消费大量 grep/read 噪音，而是通过 bash 把问题委托给只读探索 agent，后者返回短、带文件路径和行号 citation 的答案。[[flow-next-agentic-engineering-workflow

Flow-Next]] 的 fresh-context worker 则说明，长程任务不应让一个 agent 带着所有历史上下文一路推进，而应按 task 重新锚定 spec、task 和 git state。

二者共同补充了 Context Engineering 的边界：上下文质量不仅取决于材料内容，还取决于探索噪音是否隔离、证据是否可定位、每个 worker 是否只加载当前任务需要的最小上下文。对 llm-wiki 来说，正式页面也应尽量从 raw/source 中提取 cited compact claims，而不是把所有原文摘要塞入概念页。

2026-07-23 补充：上下文仓库需要 routing map 与成熟度证据

[[harness-engineering-anthology Harness Engineering Anthology]] 展示了把方法论仓库做成 agent context bundle 的模式：README、AGENTS.md、docs、playbooks、sources 共同构成可路由上下文，而不是把全部内容一次性放进 prompt。对 llm-wiki 来说，_index.md 是人类导航入口，但还可以增加面向 agent 的 routing map：按任务说明该读哪些 concept/source/playbook、哪些页面只是背景、哪些需要验证 receipt。

[[akm-eval-agentic-knowledge-management

AKM Eval]] 则提醒，上下文工程的成熟度不能只看检索命中率或页面数量，而要看 agent 是否能找到适量正确知识，并有 artifact evidence 证明 context 被使用、验证和改进。未来 llm-wiki 的 context manifest 应能回答：本次任务用了哪些页面/raw，哪些结论有来源，哪些材料被排除，是否减少了重复探索。

2026-07-26 补充：上下文应由事实路由、代码图和预算证据共同控制

[[agent-graph-fact-routed-skill-workflows

Agent Graph]] 提醒，上下文加载顺序应从“先把规则塞进 prompt”改为“先读 host facts，选择当前 route，再加载该 route 需要的资源”。[[contextiq-ast-code-graph-agent-context

ContextIQ]] 则展示代码仓库侧的结构化上下文层：AST/code graph、task-specific context pack、auto-refresh、verify-plan/verify-output 与 savings ledger。

二者共同说明：Context Engineering 的下一步不是更多文档，而是更强的 context routing 和 adoption evidence。对 llm-wiki 来说，wiki-vquery 命中、页面读取、raw 来源、未读 dropped items、index/log/vector 更新，都应逐步进入轻量 context manifest；这样才能证明知识库真的减少重复探索，而不是只扩大可搜索内容。

2026-07-28 补充：上下文图谱要从页面列表升级为关系与任务拓扑

[[graph-engineering-agent-topology

Graph Engineering]] 提醒，Context Engineering 不只是把材料放进仓库，而是要管理实体、关系、事件、来源、融合和服务给 LLM 的路径。对 llm-wiki 来说，当前 markdown + wikilink + vector search 已经解决“能找到页面”，但还没有充分解决“为什么这些页面应该一起读、哪些关系是事实依赖、哪些只是宽泛相关”。

这给上下文工程增加一个轻量方向：不要急着引入重型图数据库，而是在 source/concept frontmatter、wikilinks 和 log 中更清楚地记录 candidate → source → concept → decision 的关系。任务层也应记录 split、verifier、stop rule 和 human gate，让复杂回答或 ingest 的 context topology 可复盘。

2026-07-31 补充：工程决策层与上下文预算

contexer-engineering-decision-layer 提醒上下文工程不只是文档检索，还包括“已决策事实”的捕获、批准、版本化和跨 agent 注入。对 coding agent，项目真正稀缺的上下文常常是为什么不能用某种方案、某个事故教训、某条团队约定的适用范围；这些不应每个 session 重新推理。

contextforge-deterministic-context-budget 则把 context window 明确当作预算：Shadow Index、tier routing、filesystem memory、failure ledger 和 output compression 都是在保护工作寄存器。对 llm-wiki 来说，全局知识库、repo-local decision store、raw/source provenance、任务级 context manifest 应分层使用；否则长期 wiki 会从复利资产退化为 attention dilution。

2026-08-01 补充：scope 是上下文治理的产品边界

qm-multiplayer-agent-harness 提醒，上下文工程不只是“把知识组织得更好”，还包括“谁在什么 scope 下能看到什么”。person、room、project 级 memory/files/keychain/permissions 把上下文从全局池拆成可治理工作区。forgeos-skill-intelligence-control-plane 的 isolated ContextPack 则提供了任务级版本：每个 work unit 只加载当前 route 需要的最小上下文，并把 deterministic steps 与 evidence ledger 分开。

agentdoctor-coding-agent-config-audit 从反面说明 context hygiene：.env、private key、stale instruction、过宽 MCP 都可能把错误材料或敏感材料推入 agent 工作记忆。对 llm-wiki 来说，category、raw/source/concept、ConversationSpec、wiki-vquery 查询范围和 cron prompt 都应显式成为 context boundary；每日 radar 应记录哪些材料进入正式页面、哪些只留 raw、哪些因来源/深度不足被排除。

2026-08-02 补充：长期记忆、事实路由与轨迹上下文

optmem-permanent-agent-memory 提醒，上下文工程的长期记忆层应是 append-only、可重建、可反查的，而不是把所有 session 经验直接混进常驻 prompt。agent-graph-fact-routed-skill-workflows 则把加载策略从“累积上下文”改为“由 host facts 选择当前 route 和资源”。axisagentic-runtime-trajectory-framework 补上 runtime trace：模型可见上下文、工具事件、评测 artifact 和 provenance 应成为可恢复/可回放的事实层。

对 llm-wiki 来说，这三者合起来给出一个更清晰的分层：raw/log 是 append-only 证据，source/concept 是可重构综合，wiki-vquery/index 是检索层，radar 报告是当前 route 的输出。每日任务应继续少量深挖，并记录候选为何晋升/拒绝，避免把检索噪音压缩成长期知识。

2026-08-03 补充：示范轨迹与 catalog rubric 也是上下文

record-and-replay-skill 提醒，上下文不只有文档和代码；用户演示产生的事件流、DOM snapshot、selector candidates、截图和 replay 结果，是描述 workflow intent 的高保真上下文。awesome-agentic-devops 则提醒，catalog rubric 本身也是 context：approval、trace、maturity 和 risk label 会影响 agent 是否应该加载某个工具。

对 llm-wiki 来说，正式页面可以继续压缩为概念综合，但 raw 层应保留高保真证据；雷达报告则应记录候选为何晋升或拒绝。这样可以把“材料内容”和“材料如何被选择/使用”都变成可复盘上下文。

2026-08-05 补充：contextual error 需要可查询的影响链

agentfootprint-explainable-agent-traces 把上下文工程的失败模式具体化为 contextual error：代码没崩、工具没报错，但模型因为错误事实、过期记忆、相似工具描述或错误 steering 做出错误决策。单纯保存日志不能解释这种错误；需要把 read/write/decision/tool call/skill trigger 连接成可查询 evidence graph。

对 llm-wiki 来说，这要求重要回答和 deep ingest 留下轻量 context manifest：本次 orient 读了哪些 index/log，搜索/网页读取哪些来源，哪些 raw 被保存，哪些页面被更新，哪些候选被拒绝。这样 wiki-vquery 和 wikilinks 不只是检索层，也成为可复盘的上下文影响链。

2026-08-06 补充：上下文工程也要纳入视觉证据和 artifact 多样性

agent-vision-toolkit 提醒上下文工程不应默认为纯文本：截图、UI、图表、坐标和视觉 diff 都可能是任务的关键 evidence。更稳的做法不是让 agent 猜图，而是把视觉输入路由到 OCR、Q&A、grounding、UI diff 等窄工具，并保留可复查输出。

sitegeist-visual-convergence-benchmark 则提醒 context boundary 会影响 artifact 多样性：如果多个设计方案共享同一长上下文、历史输出或 gallery，agent 很容易重复已有模式。对 Hermes 来说，多方案生成应使用隔离 brief、反重复 rubric 和 artifact diversity check，而不是只要求“再来一个版本”。

2026-08-07 补充：上下文边界应包含 policy、verified state 与 skill manifest

longhorizon-harness-long-horizon-computer-use 说明长程任务的上下文不应无限累积，而应把 verified progress 作为最小可信状态传给 fresh-context Executor。boundary-bench-sandbox-policy-benchmark 则提醒 policy 也是上下文边界：agent 在什么网络、文件系统和权限下行动，会决定哪些策略可行、哪些失败只是边界导致。skillforge-local-first-agent-skill-runtime 补充 skill manifest 也是上下文：触发、输入输出、权限、依赖、token budget 和 eval 都应结构化，而不是藏在长 README 里。

对 llm-wiki 来说，重要 ingest/query 的 context manifest 应继续收紧：读了哪些 index/log/source，哪些 raw 被保存，哪些候选因访问边界或深度不足被排除，哪些页面/skill 是 verified state，哪些只是未复现实验的中等置信材料。

2026-08-08 补充：雷达 context manifest 与报告 claim evidence

aperture-agent-report-radar-skill 提醒，上下文工程不只发生在回答阶段，也发生在“哪些材料进入视野”的发现阶段。候选 tape、profile scoring、source registry 和 rejected-item replay 能让日报的输入上下文可复盘，避免最终 synthesis 看起来合理但无法解释选择路径。

claimproof-evidence-gated-agent-claims 则把最终报告本身变成上下文治理对象：如果报告中的“已更新/已验证/已入库”会影响下一轮 agent 或用户决策，就必须绑定当前 run 的 evidence，而不能只靠模型记忆。everdict-harness-agnostic-agent-eval-runtime 进一步提示，context provider 的改进应通过 baseline/candidate eval 证明，而不是只看主观流畅度。

对 llm-wiki 来说，下一步 context manifest 应至少记录：发现 query、候选来源、读取成功/失败、raw 文件、晋升页面、更新概念、拒绝类别、验证命令和最终报告 claims 的 receipt。这样 wiki-vquery、_index、log 和 raw 不只是存储层，也成为可评测的上下文供应链。

2026-08-09 补充：repo-local context workbench 与 skill catalog routing

repoprompt-ce-context-engineering-app 把上下文工程做成本地 macOS/MCP 工作台：从文件、CodeMaps、仓库结构和 Git diff 组装可审查、可预算的上下文，再交给 coding agents。它补充了长期 LLM-Wiki 的边界：全局 wiki 负责 durable methodology，repo-local context pack 负责当前代码状态、diff、文件图和任务预算，二者不应混成无限长 prompt。

open-science-skills-research-skill-library 与 designer-skills-agentic-design-skill-pack 则说明，技能库本身也是 context provider。高质量 domain skill 不只是提示词，而是 source-backed methods、lifecycle routing、templates、commands、报告标准和负面边界的组合。对 llm-wiki 来说，未来不仅要保存 source/concept，还应为重要任务生成 agent-facing routing map：任务类型 → 该读哪些概念/来源 → 该加载哪个 playbook/skill → 完成需要哪些 receipts。

2026-08-10 补充：上下文系统需要可审计的安全与评测上下文

[[cyclops-deterministic-mcp-toxic-flow-proxy

Cyclops]] 和 [[evalglass-local-first-agentic-app-evaluation

EvalGlass]] 从两个方向提醒：上下文不仅要相关，还要可审计。前者要求记录工具结果的可信来源、敏感性和跨调用派生关系；后者要求每个评测分数有 status、validity、provenance。

对 llm-wiki 来说，这意味着 radar 产物不应只有最终页面，还应保留候选来源、拒绝理由、raw hash、使用了哪些概念页、哪些结论是工具可验证、哪些是 LLM synthesis。这样的 context manifest 能减少未来重复探索，也能让自动化自我优化不变成无证据的规则堆叠。

2026-08-11 补充：外部 skill 与 MCP 也是上下文污染源

[[aishield-agent-tool-security-scanner

AIShield]] 提醒，上下文工程不能只优化相关性和 token 效率；外部 tool description、MCP schema、Skill Markdown、prompt 模板都可能是 injection 或供应链污染源。[[suede-creator-skills

Suede Creator Skills]] 展示了明文技能目录的可审查优势，但也提示大包安装会带来触发噪音和 standing context cost。

对 llm-wiki 来说，雷达应继续把“学习设计模式”和“安装执行资产”分开：source/concept 页面可以沉淀外部 skill 的结构；真正进入 Hermes 运行上下文前，还需要 context manifest、权限字段、安全扫描、版本锁定和 with/without-skill eval。[[claim-trace-evidence-claim-atom

claim-trace]] 则提示最终报告也属于上下文供应链：下轮 agent 可能复用今天的报告，因此每个完成声明都应尽量可追踪到文件或命令 receipt。

2026-08-13 补充：上下文质量必须包含来源权威、任务状态和可恢复工作集

agentlock-provenance-action-gate 提醒，context 不只是相关文本，还带有 authority：用户请求、系统派生数据、第三方可控内容应被区别对待。smithers-durable-agent-workflows 则说明长程任务的上下文应由持久 step 和 verified state 恢复，而不是把旧 session 全量塞回窗口。controlkeel-governed-agent-control-plane 与 aegis-architecture-aware-method-pack 进一步把团队 taste、architecture baseline、proof bundle 和 residual risk 变成 context provider。

对 llm-wiki 来说，context manifest 应新增两个字段：source authority（用户/官方/第三方/agent synthesis）和 workflow state（candidate、raw archived、source promoted、concept updated、verified、HOLD）。这样未来 agent 读取日报或页面时，能区分“可行动事实”“外部主张”和“中等置信综合”。

2026-08-14 补充：上下文影响链、信息治理与本地项目状态

[[agentfootprint-contextual-error-evidence-graph

Agentfootprint]] 把 Context Engineering 的失败模式进一步具体化为 contextual error：模型输入中的错误事实、过期记忆、相似工具描述、错误 skill/steering 或缓存上下文，会在系统不崩溃、代码不报错的情况下诱导错误答案。上下文工程因此不只是“检索相关材料”，还要能回答每个 LLM call 被哪些材料影响、谁触发、何时注入、是否新鲜。

[[doctrine-markdown-information-governance

doctrine]] 和 [[gsd-pi-local-first-agentic-project-workflow

GSD Pi]] 从治理和项目状态两侧补充：长期文档必须带 status/provenance/dependencies/freshness，长程 coding workflow 必须把 requirements、decisions、runtime notes、validation evidence 外部化为可恢复状态。对 llm-wiki 来说，raw/source/concept/log/_index/vector index 都应被看作不同保真度的 context layer；每日 radar 的深度判断、拒绝理由和写入记录就是最小 context influence chain。

2026-08-16 补充：上下文可以编译成技能，也可以保存在可恢复执行命名空间

book-to-skill-technical-book-agent-skill 和 neuroarxiv-prior-art-scouting-skill 说明 Context Engineering 的输出不一定只是 wiki 页面：当知识需要被 agent 反复操作时，可以编译成按需加载的 skill；当任务需要先研究再构建时，可以编译成 research-first gate。二者都强调先定义 purpose，再选择章节、论文、pattern 或风险，而不是把更多材料塞进上下文窗口。

pi-rlm-persistent-code-execution-tool 从执行侧补充：上下文也可以是持久 namespace 中的结构化变量、shell result objects、subagent frame records 和 snapshot restore report。相比对话 transcript，这类上下文更容易被程序消费和验证；但也需要显式 forget、权限隔离和 stale-state 检查。

对 llm-wiki 来说，下一步 context manifest 可以再分三类：raw/source/concept 是知识证据；skill/playbook 是 agent-facing compiled context；执行 receipts / namespace artifacts 是任务状态证据。不同层不应混写进一个长页面。

2026-08-17 补充：非文本上下文与 agent 资产 manifest

agent-vision-toolkit-vision-harness 提醒：截图、设计稿、GUI 状态和像素差异也是上下文，只是需要先经由视觉工具转换为 agent 可消费证据。harness-ai-kit-agent-asset-package-manager 则提醒：技能、CLI、MCP 和 loop 本身也构成上下文/能力面，需要 manifest、lock 和 runtime target 才能稳定复现。

对 llm-wiki 来说，下一步的 context engineering 不应只改检索；还要记录一次任务使用了哪些模态、哪些工具、哪些 skill 版本，以及哪些输出来自 deterministic tool result、哪些来自 LLM synthesis。

2026-08-20 补充：上下文工程正在变成 typed method 与 granular plugin

[[pipelex-declarative-ai-methods

Pipelex]] 和 [[context-engineering-kit-agent-skills

Context Engineering Kit]] 从两个方向补充了 Context Engineering：前者把 AI workflow 压缩成 typed、repeatable、composable 的 method contract；后者把工程方法论压缩成 granular、token-efficient、按需安装/加载的 skills/plugins。共同点是：上下文不再只是一段背景材料，而是带触发条件、输入输出、运行边界和验证预期的工作流资产。

对 llm-wiki 来说，这意味着每日 radar、source promotion、concept update、optimization note 都可以逐步从长 prompt discipline 收敛成 purpose bundle + method/skill manifest。正式页面应继续沉淀深知识，但执行层应避免每轮从全局 wiki 重新解释所有规则，而应按任务加载最小高信号 bundle。

写入记录

2026-08-20 09:01 CST：补充 Pipelex typed methods 与 CEK granular plugins 对上下文工程、purpose bundle、wiki radar workflow 工具化的启发。

2026-08-13 09:00 CST：补充 Prismor、AgentLock、ControlKeel、Smithers、Aegis、AAABench 对运行时控制、来源授权、持久 workflow、架构基线和长程 benchmark 的启发。

2026-08-11 09:00 CST：补充 AIShield、Suede Creator Skills、HealthClaw Guardrails、claim-trace 对 skill/MCP 安全准入、领域 guardrail、报告 claim evidence 的启发。

2026-08-09 09:00 CST：补充 HOL Guard、agent-egress-bench、RepoPrompt CE、Claw-Eval、Open Science Skills、Designer Skills 对运行时安全、上下文工作台、agent benchmark 和 domain skill routing 的启发。
2026-08-08 09:00 CST：补充 Aperture、Claimproof、Everdict 对 radar context manifest、候选选择路径和报告 claim evidence 的启发。

2026-08-07 09:00 CST：补充 Boundary-Bench、LongHorizon-Harness、SkillForge 对权限政策、已验证状态、skill runtime / manifest 和 radar 证据化的启发。

2026-08-06 09:00 CST：补充视觉证据作为上下文类型，以及 artifact diversity / context boundary 对设计生成的影响。

2026-08-05 09:00 CST：补充 AgentFootprint 对 contextual error、evidence graph 和 llm-wiki context manifest 的启发。

2026-08-03 09:00 CST：补充 Awesome Agentic DevOps、ultracodex、record-and-replay-skill、Claude Starter Kit 对 operator-safety catalog、agent-as-function、示范到 skill、tool-level gates 的启发。

2026-08-02 09:01 CST：补充 OptMem、AxisAgentic、Agent Graph、SimpleEnglish 对长期记忆、轨迹证据、事实路由 skill 和受控语言评测的启发。

2026-08-01 09:06 CST：补充 QM、ForgeOS、AgentDoctor 对 scope、ContextPack、context hygiene 和 llm-wiki context boundary 的启发。
2026-07-31 09:01 CST：补充 Contexer 与 ContextForge 对工程决策层、上下文预算、repo-local decision store 和 context manifest 分层的启发。
2026-07-28 09:00 CST：补充 Graph Engineering 对知识图谱、任务图、上下文关系质量和 llm-wiki candidate/source/concept/decision 链的启发。
2026-07-26 09:00 CST：补充 Agent Graph 与 ContextIQ 对 fact-routed context、AST code graph、context pack 和 adoption/savings evidence 的启发。
2026-07-23 09:00 CST：补充 Harness Engineering Anthology 与 AKM Eval 对 agent routing map、context bundle 和上下文成熟度证据的启发。
2026-07-21 09:01 CST：补充 Flow-Next、Harness Score、NeMo Relay、FastContext 对 agent workflow、harness scoring、runtime trajectory 或只读上下文探索的启发。

2026-07-19 09:04 CST：补充 OKFy 对 Purpose-shaped context bundle、context manifest 与 attention dilution 控制的启发。
2026-07-18 09:00 CST：补充今日 radar 对证据门控、上下文质量、技能安全或控制原语的启发。

2026-07-02 09:00 CST：补充 Context Engineering Kit 对插件化、按需加载和 token footprint 的启发。
2026-07-03 09:00 CST：补充 Enola/ACE 类项目对上下文 provider 分层的启发。
2026-07-04 09:00 CST：补充 Agent Context Workshop 对上下文 adoption、determinism 与 token efficiency 的评测启发。
2026-07-06 09:00 CST：补充 ContextNest/ContextNext 对上下文治理、版本身份、hash 和 consumption trace 的启发。
2026-07-07 09:00 CST：补充 Greplica 对持久仓库记忆、held-out planning benchmark 和 llm-wiki context-provider 评测的启发。
2026-07-10 09:00 CST：补充 Workflow as Knowledge 对 context snapshot、derive/infer 边界和 workflow 知识对象化的启发。
2026-07-11 09:00 CST：补充 memory compaction 的 rate-distortion 视角，明确上下文工程的预算、保真度和未来任务效用权衡。
2026-07-12 09:00 CST：补充 Ratel 对 tool/skill context footprint、按需工具选择和 capability retrieval 的启发。
2026-07-14 09:00 CST：补充 SETA、execute_code 工具面实验与 AIGX 对环境生成、工具面、仓库上下文格式的启发。
2026-07-15 09:02 CST：补充 ACQUIRE 对问题驱动上下文、知识缺口显式化和 deep ingest 前置合同的启发。

2026-08-10 09:00 CST：补充 2026-08-10 AI 雷达关于 context provenance、scorecard 与 radar context manifest 的更新。

2026-08-12 补充：生产 Agent 的上下文要包含预算、状态、权限和来源边界

prodagent-production-agent-framework 把 context sandwich 拆成 state / memory / skills / history / reminder，并配套五级压缩；gpu-server-setup-agent-skill 则展示了另一种上下文分层：SKILL.md 做路由，references/ 承载深资料，scripts/ 提供验证。二者共同说明，上下文工程不只是“给更多资料”，而是让 agent 在当前任务只看必要状态、技能、历史和验证路径。

对 llm-wiki 来说，每次 deep ingest 的 context manifest 应继续保留：候选来源、raw hash、晋升/拒绝理由、更新页面、验证命令和失败访问路径。这样长期知识库不会因为更多页面而增加噪音，而是形成可路由、可压缩、可审计的上下文供应链。

2026-08-31 09:00 CST：补充 ContextPilot 与 NOOA 对主动上下文行动、action-level attribution、pass-by-reference 和 candidate tape 的启发。
2026-08-12 09:00 CST：补充 ProdAgent、XORCISE、gpu-server-setup、KADATH 对生产控制面、证据评测、runbook skill 和上下文边界的启发。
2026-08-14 09:00 CST：补充 2026-08-14 雷达关于项目状态机、控制面、执行证据、上下文影响链和 skill 治理的内容。
2026-08-16 09:00 CST：补充 2026-08-16 雷达关于 RealReplicaBench、Hermes MemConflict、pi-rlm、book-to-skill、NeuroArxiv、BreachForge 的综合启发。
2026-08-17 09:00 CST：补充 2026-08-17 雷达关于 DSH/视觉 harness/skill 资产治理/脚手架/runtime seam 的启发。

2026-08-31 补充：上下文管理要从“压缩文本”升级为“记录行动”

[[contextpilot-proactive-context-management

ContextPilot]] 提醒，长程 agent 的上下文管理不应只被看作后台摘要器。planning、long-term memory、soft context offloading、search、delete、summarize、adaptive compression 都是会影响最终结果的行动，因此需要 action-level attribution：哪一次上下文编辑让任务变好，哪一次丢掉了关键证据。

[[nvidia-nooa-object-oriented-agent-harness

NOOA]] 从工程实现侧补充：最有效的上下文压缩可能不是“把所有东西摘要得更短”，而是 pass by reference。大对象、工具结果、workspace、memory store 留在外部 typed state 中，模型只看到 bounded preview，并按需调用方法查看或验证。对 llm-wiki 来说，raw/source/concept/index/log/vector index 也应被视为多层 reference system，而不是每轮全部装入上下文。

低风险落地是给 wiki-radar 保留 candidate tape：候选标题/URL、fetch 状态、晋升分数、拒绝理由、raw hash、page path、index/log/reindex receipt。这样下一次 self-optimization 才能判断哪些上下文行动有效，哪些只是增加 prompt 和报告噪音。

2026-09-01 补充：工具 registry、gateway 与 federation 本身也是上下文

MCP-Gateway-Runtime 和 [[ibm-contextforge-mcp-federation-control-plane

IBM ContextForge]] 提醒：agent 的上下文不只包括任务说明、仓库结构和长期记忆，也包括 runtime 提供的工具 registry、tool schema、backend protocol、credential owner、risk tier、rate/cost budget、trace destination 与 federation trust。

这把 Context Engineering 推到 Harness-Engineering、Loop-Engineering 和 Agent-Benchmarks 的交界处：如果工具面是动态 federation control plane，context manifest 就必须记录“本轮 agent 实际看见了哪些工具、为什么这些工具被允许、调用证据在哪里、评测是否把 gateway/harness 版本作为变量”。否则模型可能在过期工具说明、隐藏凭据边界或不可复验 route 上行动。

写入记录

2026-09-01 21:16 CST：补齐 MCP / Agent Runtime / Gateway 主题簇互链，明确本页在 runtime、context、harness、loop、benchmark 之间的分工。

2026-09-02 补充：Agent Card 是 agent 协作上下文 manifest

A2A-Agent2Agent-Protocol 把 context manifest 从工具 schema 扩展到 agent self-description：Agent Card 中的 identity、endpoint、capabilities、auth scheme、skills、input/output modes 和 examples 决定上游 agent 如何选择、调用和信任远程 agent。

因此 context management 不应只压缩 prompt 和文件，也要记录“本轮可见哪些 agent、这些 card 是否缓存/过期、哪些 sensitive skill 被选择性披露、delegation trace 是否可复验”。

写入记录

2026-09-02 21:23 CST：补充 A2A-Agent2Agent-Protocol 与本主题簇的关系，明确 A2A 在 agent-to-agent delegation、Agent Card、Discovery、task lifecycle 和实践案例雷达中的位置。

2026-09-03 补充：知识点雷达与自我优化入口

AI-Knowledge-Point-Radar 将 context management 视为长期关注轴；Agent Card、tool registry、context manifest 和上下文行动 ledger 应与 A2A-Agent2Agent-Protocol、MCP-Gateway-Runtime 互链维护。

写入记录

2026-09-03 21:00 CST：加强与 AI-Knowledge-Point-Radar、LLM-Wiki-Optimization-Log 的 wikilink 串联，统一从知识点价值和机制闭环维护本页。

2026-09-08 补充：长程 agent 的上下文成本主要是 scaffold-level replay tax

[[swe-marathon-ultra-long-horizon-agent-benchmark

SWE-Marathon]] 给 Context Engineering 一个很强的反例：更长上下文、更激进 compaction 或更多 token 不自动带来更好结果。论文报告长程 trials 的输入 token 远高于输出 token，总输出约只占 0.5%；固定模型时，不同 scaffold 的中位 token 可差 12×；部分 summarizer/compaction trials 0/71 通过；重复工具调用与长 run length 又和 timeout、行为退化相关。

这说明上下文工程的目标不是“让 agent 看见更多历史”，而是控制 replay tax、状态漂移、重复读取、无效重试和压缩损失。对 Hermes / llm-wiki 来说，长任务应记录 context manifest 与 telemetry：本轮读了哪些 page/raw、哪些工具输出被反复注入、哪些摘要替代了原始证据、重复 tool call 占比、是否用 fresh-context worker 或外部 reference store 降低注意力稀释。

写入记录

2026-09-08 09:01 CST：补充 SWE-Marathon 对长程 agent context replay tax、scaffold-dependent token cost、compaction 风险和 Hermes context telemetry 的启发。

2026-09-09 补充：工具/接口 manifest 需要可选择性与可验证性

[[osworld-mcp-tool-invocation-computer-use-benchmark OSWorld-MCP]] 说明工具列表本身就是高成本上下文：158 个 MCP tools 与 25 个 distractors 如果全部进入 prompt，会增加选择负担和误用风险。[[a2a-v1-protocol-binding-governance A2A v1]] 则说明 Agent Card 不能压成一段自然语言简介；supportedInterfaces[]、protocolVersion、auth、extensions、signature、extended card policy 都是上游 agent 选择和信任远程 agent 的结构化上下文。

[[agenttrust-runtime-safety-interception

AgentTrust]] 再补一层：安全上下文不是完整聊天记录，而是 action ledger 与 RiskChain。Hermes 的 context manifest 因此应区分三类对象：可见能力（tools/agents/interfaces）、选择证据（为什么当前任务选择它）、安全状态（此前动作是否形成风险链）。这比“更多上下文”更重要。

写入记录

2026-09-09 09:01 CST：补充 tool manifest、AgentInterface manifest 与 action-ledger/RiskChain 对上下文选择、验证和安全状态的启发。
2026-09-11 09:09 CST：补充 ARC 地址回读与 SPA 标签保留的简短机制入口；不复制 source 长文，不将持久化视为可信化。