如何用 context-compression 技能的探针式提问评估智能体上下文压缩质量【免费下载链接】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长会话智能体做上下文压缩后最常见的担忧是文件路径、报错信息和关键决策是不是被压丢了。Agent-Skills-for-Context-Engineering 仓库中的 context-compression 技能内置了一套探针式评估probe-based evaluation压缩完成后向模型提出若干定向问题如果模型还能正确回答被截断历史里的关键信息说明压缩保住了该有的内容如果答不上来说明它在靠猜或幻觉。这套能力由 压缩评估脚本 和 评估框架参考文档 组成只需要 Python 3 标准库无任何第三方依赖。为什么用探针而不是 ROUGE 之类的指标SKILL.md 在 Evaluate Compression with Probes, Not Metrics 一节中给出了理由ROUGE、嵌入相似度等传统指标无法捕捉功能性压缩质量——摘要可以在词汇重叠度上得分很高却恰好丢了智能体继续工作所需的那条文件路径。探针式评估的做法是压缩发生后构造问题测试关键信息是否存活并用回答的正确性判断压缩质量。技能定义了四类探针每类对应一种信息损失风险探针类型测试什么示例问题Recall事实回忆事实保留What was the original error message?Artifact文件追踪文件追踪Which files have we modified?Continuation任务延续任务规划What should we do next?Decision决策推理推理链What did we decide about the Redis issue?更细的探针结构Question / Expected / Scoring 三要素和每类的更多示例问题见 evaluation-framework.md 的 Probe Types 一节。评估脚本提供的三个组件compression_evaluator.py 是一个独立脚本公开 API 有三个部分文档字符串中有各自的使用时机说明ProbeGenerator接收完整会话历史用正则模式匹配抽取事实断言错误信息、下一步任务、文件操作modified / created / read 句式和决策点decided to / chose / going with / will use 句式最多 5 条然后按类别生成带ground_truth的探针列表。CompressionEvaluator对单条探针回答按六个维度的评分细则打分evaluate()每次评估一条探针get_summary()汇总所有结果。evaluate_compression_quality(original_history, compressed_context, model_response_fn)一站式入口内部完成生成探针 → 逐条收集模型回答 → 评分 → 汇总并给出建议。脚本顶部的 PRODUCTION NOTES 明确提示LLM judge 调用是演示用桩stub生产系统应接入真实模型 APItoken 估算用简化启发式ground truth 抽取用模式匹配生产环境可换成更精细的事实抽取。先跑自带 demo 确认环境可用在仓库根目录下直接运行python3 skills/context-compression/scripts/compression_evaluator.py脚本__main__块内置了一段调试 401 错误的样例会话历史、对应的结构化压缩摘要和一个模拟模型回答函数会完整走一遍评估流程。上面命令的示例输出如下 Compression Quality Evaluation Total evaluations: 4 Average score: 3.25 Dimension averages: accuracy: 3.25 context_awareness: 3.25 completeness: 3.25 instruction_following: 3.25 artifact_trail: 4.00 continuity: 3.25 Weakest dimension: accuracy Strongest dimension: artifact_trail Recommendations: - Compression quality is below threshold - consider less aggressive compression这段输出来自 demo 内置的样例数据和桩打分器用于确认脚本可以跑通不代表你自有压缩产物的真实质量。用探针评估一次真实压缩拿到自己的两份数据后压缩前的完整会话历史original_history以及压缩后的上下文compressed_context。核心是向评估器提供一个回答函数其签名为(compressed_context, question) - str即只给压缩后的上下文让模型回答探针问题。下面按脚本 demo 的方式组织代码把脚本目录加入sys.path以便导入import sys sys.path.insert(0, skills/context-compression/scripts) from compression_evaluator import evaluate_compression_quality original_history User reported error: 401 Unauthorized on /api/auth/login endpoint. Examined auth.controller.ts - JWT generation looks correct. Modified config/redis.ts: Fixed connection pooling configuration. Decided to use Redis connection pool instead of per-request connections. 14 tests passing, 2 failing (mock setup issues). Next: Fix remaining test failures in session service mocks. compressed_context ## Session Intent Debug 401 Unauthorized on /api/auth/login. ## Files Modified - config/redis.ts: Fixed connection pooling ## Next Steps 1. Fix remaining test failures 以上两个字符串取自脚本__main__demo 中的样例值替换成你自己的会话历史和压缩摘要。model_response_fn必须是真实调用把compressed_context作为上下文发给你的模型把probe.question作为提问返回模型的回答。demo 里用关键词匹配的mock_model_response只是为了演示流程生产评估必须换成真实模型调用否则测的不是压缩质量。然后result evaluate_compression_quality( original_historyoriginal_history, compressed_contextcompressed_context, model_response_fnmy_model_answer, # 你自己的 (context, question) - str ) print(result[average_score], result[dimension_averages], result[recommendations])如果你需要逐条查看每个探针的打分和理由可以手动组合ProbeGenerator和CompressionEvaluator先ProbeGenerator(original_history).generate_probes()拿到探针列表recall、artifact、continuation、decision各一条其中 recall/artifact/decision 只在历史里抽到对应内容时才生成continuation 恒定生成再对每条探针调用evaluator.evaluate(probe, response, compressed_context)最后evaluator.get_summary()汇总。判读结果看四个汇总字段get_summary()/evaluate_compression_quality()返回的字典包含这些字段分值为 0–5 的评分尺度total_evaluations实际评估的探针条数最多 4取决于历史中能抽到什么average_score所有探针综合得分的均值dimension_averages各维度平均分覆盖 accuracy、context_awareness、artifact_trail、completeness、continuity、instruction_following 六个维度weakest_dimension/strongest_dimension最低和最高分维度。评分细则定义在脚本的RUBRIC_CRITERIA中六个维度、14 条加权标准如 accuracy 下accuracy_factual权重 0.6、accuracy_technical权重 0.4维度分是标准分的加权平均综合分是维度分的简单平均。evaluation-framework.md 中给出了每条标准在 0 / 3 / 5 分上的判定描述例如 artifact 维度的artifact_files_modified0 分完全不知道改过哪些文件3 分对大部分修改有较好了解5 分完整知道所有修改。evaluate_compression_quality还会追加recommendations列表触发条件有两个最弱维度是artifact_trail时建议 Consider implementing separate artifact tracking outside compression在压缩之外做独立的文件状态追踪average_score 3.5时建议 Compression quality is below threshold - consider less aggressive compression压缩过激建议降低压缩强度。压缩评估单元测试 验证了桩打分器的两个行为提到具体文件路径的回答比含糊回答得分更高且与 ground truth 匹配的简单文本得分高于不匹配的可用于回归检查脚本行为。生产环境把启发式打分换成 LLM judge演示版CompressionEvaluator的打分是启发式的基础分 3.0按回答长度、是否含文件引用、与 ground truth 的词汇重叠调整脚本文档字符串建议生产系统替换为真实 LLM judge 调用。evaluation-framework.md 提供了替换所需的完整规格Judge 输入格式每次评估一条探针时组装{ probe_question: What was the original error message?, model_response: [Response to evaluate], compacted_context: [The compressed context that was provided], ground_truth: [Optional: known correct answer], rubric_criteria: [accuracy_factual, accuracy_technical, context_conversation_state] }Judge 输出格式评分结果应回解析为这个结构reasoning为文档示例中的文字{ criterionResults: [ { criterionId: accuracy_factual, score: 5, reasoning: Response correctly identifies the 401 error, specific endpoint, and root cause. } ], aggregateScore: 4.8, dimensionScores: { accuracy: 4.9, context_awareness: 4.5, artifact_trail: 3.2, completeness: 5.0, continuity: 4.8, instruction_following: 5.0 } }该文档还给出评分流程五步送 judge → 按 rubric 逐标准评分 → 输出结构化 JSON → 维度分取加权平均 → 总分取维度分不加权平均并要求blinding盲评judge 不应知道被评估的回答出自哪种压缩方法以避免对已知方法的偏好。评分时使用的系统提示词0–5 分、只依据回答中实际存在的内容打分也在同一文档中可直接采用。限制与已知盲区探针存在假信心探针只测它问到的内容。一组只查文件名、不查函数签名的探针会漏掉签名丢失。SKILL.md 的 Gotchas 建议探针设计要覆盖全部六个评分维度并在多次评估之间轮换探针集合。自动探针抽取基于正则ProbeGenerator靠error:/TODO:/modified xxx.ts等固定句式抽取 ground truth句式不符合时对应类别的探针不会生成continuation 除外。脚本文档字符串建议在需要更高召回时用 LLM 抽取器替换正则逻辑。artifact 维度普遍偏弱evaluation-framework.md 引用的 36,000 消息基准中三种压缩方法的 artifact 分都在 2.19–2.45 之间是该基准中最弱维度SKILL.md 同时注明这些分数属于来源特定的基准数字不是通用常量。如果评估显示artifact_trail是最弱维度文档给出的对策是在智能体脚手架里维护独立的文件状态索引而不是依赖摘要器自己记住。桩打分器不代表真实质量demo 输出的 3.25 这类数字来自演示数据加启发式规则换成真实模型回答和 LLM judge 后数值不可直接比较。完成一次探针评估后若需要扩展到压缩之外的通用 LLM-as-judge 方法论仓库中的 evaluation 技能 和 advanced-evaluation 技能 是 SKILL.md Integration 一节明确指出的延伸阅读。【免费下载链接】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），仅供参考
如何用 context-compression 技能的探针式提问评估智能体上下文压缩质量？
如何用 context-compression 技能的探针式提问评估智能体上下文压缩质量【免费下载链接】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长会话智能体做上下文压缩后最常见的担忧是文件路径、报错信息和关键决策是不是被压丢了。Agent-Skills-for-Context-Engineering 仓库中的 context-compression 技能内置了一套探针式评估probe-based evaluation压缩完成后向模型提出若干定向问题如果模型还能正确回答被截断历史里的关键信息说明压缩保住了该有的内容如果答不上来说明它在靠猜或幻觉。这套能力由 压缩评估脚本 和 评估框架参考文档 组成只需要 Python 3 标准库无任何第三方依赖。为什么用探针而不是 ROUGE 之类的指标SKILL.md 在 Evaluate Compression with Probes, Not Metrics 一节中给出了理由ROUGE、嵌入相似度等传统指标无法捕捉功能性压缩质量——摘要可以在词汇重叠度上得分很高却恰好丢了智能体继续工作所需的那条文件路径。探针式评估的做法是压缩发生后构造问题测试关键信息是否存活并用回答的正确性判断压缩质量。技能定义了四类探针每类对应一种信息损失风险探针类型测试什么示例问题Recall事实回忆事实保留What was the original error message?Artifact文件追踪文件追踪Which files have we modified?Continuation任务延续任务规划What should we do next?Decision决策推理推理链What did we decide about the Redis issue?更细的探针结构Question / Expected / Scoring 三要素和每类的更多示例问题见 evaluation-framework.md 的 Probe Types 一节。评估脚本提供的三个组件compression_evaluator.py 是一个独立脚本公开 API 有三个部分文档字符串中有各自的使用时机说明ProbeGenerator接收完整会话历史用正则模式匹配抽取事实断言错误信息、下一步任务、文件操作modified / created / read 句式和决策点decided to / chose / going with / will use 句式最多 5 条然后按类别生成带ground_truth的探针列表。CompressionEvaluator对单条探针回答按六个维度的评分细则打分evaluate()每次评估一条探针get_summary()汇总所有结果。evaluate_compression_quality(original_history, compressed_context, model_response_fn)一站式入口内部完成生成探针 → 逐条收集模型回答 → 评分 → 汇总并给出建议。脚本顶部的 PRODUCTION NOTES 明确提示LLM judge 调用是演示用桩stub生产系统应接入真实模型 APItoken 估算用简化启发式ground truth 抽取用模式匹配生产环境可换成更精细的事实抽取。先跑自带 demo 确认环境可用在仓库根目录下直接运行python3 skills/context-compression/scripts/compression_evaluator.py脚本__main__块内置了一段调试 401 错误的样例会话历史、对应的结构化压缩摘要和一个模拟模型回答函数会完整走一遍评估流程。上面命令的示例输出如下 Compression Quality Evaluation Total evaluations: 4 Average score: 3.25 Dimension averages: accuracy: 3.25 context_awareness: 3.25 completeness: 3.25 instruction_following: 3.25 artifact_trail: 4.00 continuity: 3.25 Weakest dimension: accuracy Strongest dimension: artifact_trail Recommendations: - Compression quality is below threshold - consider less aggressive compression这段输出来自 demo 内置的样例数据和桩打分器用于确认脚本可以跑通不代表你自有压缩产物的真实质量。用探针评估一次真实压缩拿到自己的两份数据后压缩前的完整会话历史original_history以及压缩后的上下文compressed_context。核心是向评估器提供一个回答函数其签名为(compressed_context, question) - str即只给压缩后的上下文让模型回答探针问题。下面按脚本 demo 的方式组织代码把脚本目录加入sys.path以便导入import sys sys.path.insert(0, skills/context-compression/scripts) from compression_evaluator import evaluate_compression_quality original_history User reported error: 401 Unauthorized on /api/auth/login endpoint. Examined auth.controller.ts - JWT generation looks correct. Modified config/redis.ts: Fixed connection pooling configuration. Decided to use Redis connection pool instead of per-request connections. 14 tests passing, 2 failing (mock setup issues). Next: Fix remaining test failures in session service mocks. compressed_context ## Session Intent Debug 401 Unauthorized on /api/auth/login. ## Files Modified - config/redis.ts: Fixed connection pooling ## Next Steps 1. Fix remaining test failures 以上两个字符串取自脚本__main__demo 中的样例值替换成你自己的会话历史和压缩摘要。model_response_fn必须是真实调用把compressed_context作为上下文发给你的模型把probe.question作为提问返回模型的回答。demo 里用关键词匹配的mock_model_response只是为了演示流程生产评估必须换成真实模型调用否则测的不是压缩质量。然后result evaluate_compression_quality( original_historyoriginal_history, compressed_contextcompressed_context, model_response_fnmy_model_answer, # 你自己的 (context, question) - str ) print(result[average_score], result[dimension_averages], result[recommendations])如果你需要逐条查看每个探针的打分和理由可以手动组合ProbeGenerator和CompressionEvaluator先ProbeGenerator(original_history).generate_probes()拿到探针列表recall、artifact、continuation、decision各一条其中 recall/artifact/decision 只在历史里抽到对应内容时才生成continuation 恒定生成再对每条探针调用evaluator.evaluate(probe, response, compressed_context)最后evaluator.get_summary()汇总。判读结果看四个汇总字段get_summary()/evaluate_compression_quality()返回的字典包含这些字段分值为 0–5 的评分尺度total_evaluations实际评估的探针条数最多 4取决于历史中能抽到什么average_score所有探针综合得分的均值dimension_averages各维度平均分覆盖 accuracy、context_awareness、artifact_trail、completeness、continuity、instruction_following 六个维度weakest_dimension/strongest_dimension最低和最高分维度。评分细则定义在脚本的RUBRIC_CRITERIA中六个维度、14 条加权标准如 accuracy 下accuracy_factual权重 0.6、accuracy_technical权重 0.4维度分是标准分的加权平均综合分是维度分的简单平均。evaluation-framework.md 中给出了每条标准在 0 / 3 / 5 分上的判定描述例如 artifact 维度的artifact_files_modified0 分完全不知道改过哪些文件3 分对大部分修改有较好了解5 分完整知道所有修改。evaluate_compression_quality还会追加recommendations列表触发条件有两个最弱维度是artifact_trail时建议 Consider implementing separate artifact tracking outside compression在压缩之外做独立的文件状态追踪average_score 3.5时建议 Compression quality is below threshold - consider less aggressive compression压缩过激建议降低压缩强度。压缩评估单元测试 验证了桩打分器的两个行为提到具体文件路径的回答比含糊回答得分更高且与 ground truth 匹配的简单文本得分高于不匹配的可用于回归检查脚本行为。生产环境把启发式打分换成 LLM judge演示版CompressionEvaluator的打分是启发式的基础分 3.0按回答长度、是否含文件引用、与 ground truth 的词汇重叠调整脚本文档字符串建议生产系统替换为真实 LLM judge 调用。evaluation-framework.md 提供了替换所需的完整规格Judge 输入格式每次评估一条探针时组装{ probe_question: What was the original error message?, model_response: [Response to evaluate], compacted_context: [The compressed context that was provided], ground_truth: [Optional: known correct answer], rubric_criteria: [accuracy_factual, accuracy_technical, context_conversation_state] }Judge 输出格式评分结果应回解析为这个结构reasoning为文档示例中的文字{ criterionResults: [ { criterionId: accuracy_factual, score: 5, reasoning: Response correctly identifies the 401 error, specific endpoint, and root cause. } ], aggregateScore: 4.8, dimensionScores: { accuracy: 4.9, context_awareness: 4.5, artifact_trail: 3.2, completeness: 5.0, continuity: 4.8, instruction_following: 5.0 } }该文档还给出评分流程五步送 judge → 按 rubric 逐标准评分 → 输出结构化 JSON → 维度分取加权平均 → 总分取维度分不加权平均并要求blinding盲评judge 不应知道被评估的回答出自哪种压缩方法以避免对已知方法的偏好。评分时使用的系统提示词0–5 分、只依据回答中实际存在的内容打分也在同一文档中可直接采用。限制与已知盲区探针存在假信心探针只测它问到的内容。一组只查文件名、不查函数签名的探针会漏掉签名丢失。SKILL.md 的 Gotchas 建议探针设计要覆盖全部六个评分维度并在多次评估之间轮换探针集合。自动探针抽取基于正则ProbeGenerator靠error:/TODO:/modified xxx.ts等固定句式抽取 ground truth句式不符合时对应类别的探针不会生成continuation 除外。脚本文档字符串建议在需要更高召回时用 LLM 抽取器替换正则逻辑。artifact 维度普遍偏弱evaluation-framework.md 引用的 36,000 消息基准中三种压缩方法的 artifact 分都在 2.19–2.45 之间是该基准中最弱维度SKILL.md 同时注明这些分数属于来源特定的基准数字不是通用常量。如果评估显示artifact_trail是最弱维度文档给出的对策是在智能体脚手架里维护独立的文件状态索引而不是依赖摘要器自己记住。桩打分器不代表真实质量demo 输出的 3.25 这类数字来自演示数据加启发式规则换成真实模型回答和 LLM judge 后数值不可直接比较。完成一次探针评估后若需要扩展到压缩之外的通用 LLM-as-judge 方法论仓库中的 evaluation 技能 和 advanced-evaluation 技能 是 SKILL.md Integration 一节明确指出的延伸阅读。【免费下载链接】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），仅供参考
