论文 · 工程 · 实践

推荐.

134 篇推荐 · 8 个主题

值得读的 Agent 论文与工程实践。

论文

AIOpsOops:保留诊断关系,隔离不可信遥测文本

关注的问题

运维 Agent 把低权限用户能写入的遥测内容当成故障解释,可能在仍然执行合法修复任务时提出危险操作;只检测显眼的指令覆盖容易漏掉这种诱导。 防御若直接删除所有遥测,会同时破坏根因分析需要的结构和关联信息;需要在移除可控文本的同时保留可用的诊断上下文。

作者的方法

作者构造经应用遥测进入 Agent 的任务相关诱导,并用跨应用、模型和 Agent 的对照测量它如何改变修复建议。 作者先识别可控遥测字段,运行时只把这些字段替换成稳定的带类型标识,保留日志结构与重复值之间的关联。

  • 安全与隔离
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

论文针对读取遥测、定位故障并建议或执行修复的运维 Agent。遥测包含应用自己生成的结构,也可能含外部请求留下的用户字段;传统日志防护并不自动保证模型能够区分这两种信息的权限。 §1–3.1,pp.4841–4844;Fig.1

合法任务也会接受不可信的故障解释

日志条目并非每个字段都由系统可信地产生。外部请求中的文本一旦记录进遥测,就可能与错误码和内部诊断材料一起呈现给模型;作者关注的是模型继续努力修复故障,却把这些文本当作解决方案的依据。直接删除整条日志又会损失定位故障需要的关系。 §1–3.1,pp.4841–4844;Fig.1原文依据原文依据

02 文章用了什么方法

先区分诱导方式与投递通道

作者通过用户可控字段进入遥测,构造与当前运维任务相符的故障解释和建议。评价同时覆盖应用、Agent、模型及修复目标,并在固定投递方式下替换成常见指令覆盖形式,以区分这类任务相关诱导与一般触发语的效果。 原文依据原文依据原文依据

用稳定字段抽象保留诊断结构

防御的设置阶段用标记值寻找进入遥测的可控参数,再从这些记录建立带字段标签的模板。严格格式采用 schema,松散日志采用生成的正则表达式,并检查能否正确匹配和提取标记;这些检查提高可用性,但仍是启发式。 原文依据

运行时防御在工具输出进入模型前应用模板,把可控文本改成带类型的稳定标识。相同值在不同记录和运行中仍保留同一抽象名,使关联分析不必接触原始文字;原始遥测仍保存,供人进一步检查。 §5.1.2,p.4853;Fig.9,已本地渲染查看

03 证据支持到哪里

成功指标是建议匹配而非实际破坏

180 次攻击覆盖 36 个配置,每个配置运行 5 次。作者报告 90% 成功率,判定对象是 Agent 输出的修复建议是否匹配目标,由不同模型判断并对约 10% 结果手审。因此它说明决策受操纵,不能直接读成基础设施被破坏的概率。 原文依据

配置矩阵包括3个应用、2类Agent、2个模型和3类目标,各次从重置环境开始并限制为35轮。常见诱导形式的负对照固定在一个应用与Agent/模型组合,不能代表所有配置;逐行检测器对照也只测这一部署口径。论文没有用相同总token预算隔离模型能力与所有上下文策略的贡献。 原文依据原文依据

套用 84、12、132 个模板后,原攻击组中没有成功案例。正常任务对照采用 Flash 和 GPT4.1,12 个任务各运行 3 次,有防御成功17/36,无防御成功18/36;结果支持在该样本中保留大部分任务能力,而非证明所有诊断信息都可以无成本删除。 原文依据

字段覆盖就是防御的实际边界

模板化防御只处理设置阶段已经发现且能够解析的字段。论文明确承认遗漏入口、结构异常的日志及被攻陷工具等更强输入渠道不在同一保障内。检测器对照也采用逐行检查,不能用结果概括所有检测部署方式;实验全部发生在隔离合成环境。 原文依据原文依据原文依据

统计呈现仍有一处需保留疑问。Figure7列出的失败类别合计20,但正文同时报告180次与平均90%成功率,未完全解释聚合口径;因此这里保留作者报告的百分比,不反推出162次成功这一原文未确认的计数。 原文依据

04 总结与启发

AIOpsOops 表明保持合法任务并不能阻止遥测诱导;可控字段的稳定抽象提供了一种保留结构、减少模型接触攻击语义的防御。

我们的理解与启发

把关联价值与文本解释权拆开

这里值得迁移的选择是保留上下文的结构与相等关系,同时移除低权限字段直接解释故障的能力。对于只需知道同一用户或请求是否重复出现的运维任务,稳定标识有明确价值;对于必须阅读用户自由文本才能完成的任务,该抽象会丢失核心语义,因此不能照搬。写操作权限仍需由独立机制约束。 原文依据§5.1.2,p.4853;Fig.9,已本地渲染查看原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 运维 Agent 把低权限用户能写入的遥测内容当成故障解释,可能在仍然执行合法修复任务时提出危险操作;只检测显眼的指令覆盖容易漏掉这种诱导。

primary §1–3.1,pp.4841–4844;Fig.1原文依据原文依据

P2 · 防御若直接删除所有遥测,会同时破坏根因分析需要的结构和关联信息;需要在移除可控文本的同时保留可用的诊断上下文。

primary 原文依据§5.1.2,p.4853;Fig.9,已本地渲染查看原文依据

D1 · 作者构造经应用遥测进入 Agent 的任务相关诱导,并用跨应用、模型和 Agent 的对照测量它如何改变修复建议。

将投递通道与语义诱导分开考察,保持合法任务不变而替换被解释的故障信息,暴露把日志内容当修复依据的信任边界。

core · described · diagnose · 对应问题 P1 原文依据原文依据原文依据

D2 · 作者先识别可控遥测字段,运行时只把这些字段替换成稳定的带类型标识,保留日志结构与重复值之间的关联。

攻击文本在进入模型前被抽象;相同输入值仍映射同一名称,使跨日志关联可继续使用。其有效性依赖设置阶段覆盖这些字段和模板正确匹配。

core · described · mitigate · 对应问题 P2P1 原文依据§5.1.2,p.4853;Fig.9,已本地渲染查看原文依据

E1 §1–3.1,pp.4841–4844;Fig.1 原文描述

AIOps Agent 将遥测用于根因分析和修复;外部攻击者不具备内部权限,但请求参数能被合法日志或 trace 记录并进入 Agent 上下文。

外部低权限、非自适应攻击威胁模型;已控制工具或供应链属于更强模型。

查看原文 ↗

E2 §3.2–3.5,pp.4844–4848;Fig.2–5;Appendix E 原文描述

攻击框架识别可进入遥测的用户字段;内容保持根因分析任务的表面目标,用貌似合理的故障解释和修复建议误导 Agent,而不是直接要求放弃任务。

机制说明及样例;没有真实生产受害事件,本文不提供攻击执行步骤。

查看原文 ↗

E3 §4.1–4.2,pp.4848–4850;Fig.6–7 作者报告结果

36 配置各 5 次共 180 次实验,覆盖 3 应用、2 Agent、2 模型及 3 类修复目标;ASR 定义为输出修复与预期匹配,o4-mini 判断并手审约 10% 的 20 次;整体 ASR 作者报告 90%。

输出语义匹配并不等于真实执行或基础设施被破坏;每次重置独立 VM。

查看原文 ↗

E4 §4.2.1,p.4851;Appendix B,pp.4858–4859 作者报告结果

固定容易配置下替换为十种标准注入触发语,所测攻击全部失败;检测器逐行分析输入,PromptShields、PromptGuard2 未识别所测攻击内容,DataSentinel 召回 15%。

仅支持所测试配置与逐行检测方式,不能概括全部通用提示注入或全部防御器。

查看原文 ↗

E5 §5.1.1,pp.4852–4853;Fig.8,已本地渲染查看;Appendix C,p.4859 原文描述

防御设置阶段用 canary 标识进入遥测的可控字段,生成模板及参数标签;松散格式使用 LLM 生成 regex,严格格式生成 schema;随机字符替换和匹配反馈检查是启发式。

覆盖依赖端点枚举和 fuzzing;regex 的所有输入正确性没有保证。

查看原文 ↗

E6 §5.1.2,p.4853;Fig.9,已本地渲染查看 原文描述

运行时在遥测抵达 Agent 前匹配模板,把可控参数变成类型标签加唯一标识;同一个值跨运行保持相同抽象名,重组遥测但保留原始日志供人查看。

保留结构和相等关系,移除原始用户文本;未匹配模板不受此保障。

查看原文 ↗

E7 §5.1.3,pp.4853–4854;Appendix D / Table D.1,pp.4859–4860 作者报告结果

三应用分别生成 84、12、132 个模板后,原攻击组未再成功。12 个无攻击任务各 3 次,Flash+GPT4.1 的成功次数为无防御 18/36、有防御 17/36。

所测攻击与小样本任务上的结果;不构成普适防御或零 utility 成本证明。

查看原文 ↗

E8 §5.1.3 和 Ethical Considerations,p.4854;Appendix A.1,p.4858 原文描述

作者承认模板未覆盖、不能结构化的遥测及其他输入渠道可绕过边界;全部实验为隔离合成环境。附录 A.1 正文任务类别与 Table A.1 列标签不一致。

收录结论限于可枚举的结构化遥测入口,不引用该附录类别差异作为有效性依据。

查看原文 ↗

原始来源

论文

AVA:用事件图扩展上下文,再回到原始证据

关注的问题

长视频问答只按当前问题检索相似帧,容易丢失事件前后经过和跨片段实体关系;把全部视频放进模型上下文又受窗口与成本限制。

作者的方法

作者将视频持续整理为保留时间顺序、实体关系和原始帧链接的事件图,使检索能从相关片段继续找到相邻事件与关联证据。 作者从事件、实体和原始帧三路选择起点,再用受限动作树扩充上下文,并通过候选一致性和原始帧核查筛选答案。

  • 记忆与上下文
  • 文件与工件
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

论文研究长时视频的开放式问答。已有 VLM 受上下文长度限制,视频 RAG 往往先找与问题相似的帧,再交给模型作答;这种流程难以把前后事件和多次出现的实体组织成可追踪的上下文。 §1–3,pp.1939–1942;Fig.2

相似片段不足以回答事件经过

问题中的关键词不一定描述了答案所需的全部过程。一个命中片段可能只给出事件结果,模型还需知道之前发生了什么、同一实体在哪里再次出现。论文因此把困难落在证据组织与上下文扩展,而不是单纯扩大模型窗口。 §1–3,pp.1939–1942;Fig.2

02 文章用了什么方法

先构造能回到原视频的事件索引

索引先把短缓冲区的视觉描述按语义一致性合并,减少在事件中间切断上下文。系统再抽取事件、实体与时间关系,把实体向量聚类并保留原始帧链接。后续查询既能沿结构关系扩展,也能返回摘要生成前的视觉材料。 原文依据

事件合并依据描述相似度而非固定长片段。默认每3秒形成一个短描述,只有合并块中描述两两BERTScore都超过0.65才继续合并;BERTScore在这里衡量文本语义相似性。图中事件有时间边,实体通过参与关系连接事件,原帧链接则保留摘要可能漏掉的细节。 原文依据

检索起点之后仍要补充和核查证据

三路检索分别使用事件描述、实体和原始帧,再把排名合并为事件列表。系统按预定义的前进、后退、重查询与总结动作展开树,限制深度和列表长度;这是一套有边界的搜索流程,而非让模型任意选择下一步。 原文依据

每条候选路径重复作答后,系统结合答案一致性与推理文本相似度选择候选,再对两个不同答案节点读取原始帧检查。这个安排将证据选择与最终核查分开,但一致性分数本身并不证明答案正确。 §5.3,pp.1946–1947;Eq.4–6

一致性评分把反复生成的答案与理由分开比较。每个总结节点生成8次,以答案频率和理由之间的语义相似度加权排名;随后选排名靠前且答案不同的两个候选,由视觉语言模型查看对应原帧后裁定。这样的回查能质疑摘要,但重复输出相似本身不构成事实正确性证明。 §5.3,pp.1946–1947;Eq.4–6

03 证据支持到哪里

收益与成本要在同一配置下理解

作者报告LVBench、VideoMME-Long、AVA-100的总体正确率分别为62.3%、64.1%和75.8%。其中 AVA-100 有 8 个视频、99.2 小时和 120 道题,部分视频由较短素材拼接;这些结果支持所测长视频问答能力,不能外推为真实连续生活流上的普遍表现。 原文依据

查询的主要代价来自树搜索。Table 2 的单 A100 测量中,初始检索为 0.44 秒,而 Qwen14B/32B 搜索分别为 101.5/174.2 秒,视觉核查还需额外时间。索引处理速度超过 2 FPS 输入采样,只说明索引能够跟上采样流。 原文依据

测量协议同时包含总体比较、部件消融和分阶段耗时。AVA-100的问题与正确答案由人构造,干扰选项由GPT-4o生成后人工核验;组件消融只覆盖20个视频的305道题。默认系统分别用不同模型完成索引、搜索和视觉裁定,因而总体排行榜不能独立归因于事件图;论文也没有给出所有比较的配对不确定性估计。 原文依据原文依据原文依据

增加搜索深度并不保证质量

深度消融呈现明确反例:Qwen14B+Gemini 从深度 3 到 4,准确率由 61.5% 降至 52.7%,搜索时间由 90.1 秒增至 370.3 秒。另一个边界是图索引对照的文字说明:作者先说基线采用同样语义描述,后又用均匀片段解释收益,因此不宜把该对照读成语义切分的独立因果证据。 原文依据

04 总结与启发

AVA 把长视频组织为可扩展检索的事件关系,并在生成后回查视觉证据;主要代价在多路径查询,而不是初始向量检索。

我们的理解与启发

把上下文扩展能力与预算一起设计

可迁移部分是显式事件关系与原始证据回查通道。对于后台 Agent 分析任务,允许沿时间和实体扩展上下文具有实际价值;对于交互任务,本文给出的分钟级搜索成本意味着必须重新选择预算。应把可追踪的证据结构与具体搜索深度区分开来采用。 原文依据原文依据§5.3,pp.1946–1947;Eq.4–6原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 长视频问答只按当前问题检索相似帧,容易丢失事件前后经过和跨片段实体关系;把全部视频放进模型上下文又受窗口与成本限制。

primary §1–3,pp.1939–1942;Fig.2

D1 · 作者将视频持续整理为保留时间顺序、实体关系和原始帧链接的事件图,使检索能从相关片段继续找到相邻事件与关联证据。

语义合并减少固定切片割裂事件的情况,显式事件关系支持后续跳转,原始帧链接保留返回视觉证据的通道。

core · described · mitigate · 对应问题 P1 原文依据

D2 · 作者从事件、实体和原始帧三路选择起点,再用受限动作树扩充上下文,并通过候选一致性和原始帧核查筛选答案。

三视图弥补单一文本匹配的遗漏;前后跳转和重查询补充起始命中之外的材料;长度与深度限制控制上下文扩张,最终核查降低只信描述摘要的风险。

core · described · mitigate · 对应问题 P1 原文依据§5.3,pp.1946–1947;Eq.4–6

E1 §1–3,pp.1939–1942;Fig.2 原文描述

长视频受到上下文窗口限制;基于单帧相似度的检索缺少未显式出现在查询中的时间上下文;系统以事件索引与多路径检索回答开放问题。

问题与架构动机,不是生产部署证据。

查看原文 ↗

E2 §4.1–4.3,pp.1942–1945;Eq.1;Fig.3–4 原文描述

3 秒缓冲描述通过语义一致性合并;事件、实体及时间关系分别建表;实体向量聚类去重;原始帧保留向量并链接到事件。

描述抽取依赖小 VLM,语义阈值为本文调参值;事件图不是完美现实事实库。

查看原文 ↗

E3 §5.1–5.2,pp.1945–1946;Eq.2–3;Fig.5–6 原文描述

事件描述、实体、原始帧三路检索经归一化加权 Borda 合并,随后固定前进、后退、重查询、总结回答动作展开树;深度 3 有 13 条路径,事件列表最多 16 项。

预定义动作树搜索,不能称为学得的自适应规划策略。

查看原文 ↗

E4 §5.3,pp.1946–1947;Eq.4–6 原文描述

候选答案重复生成,以答案一致性和同答案推理文本的 BERTScore 组合评分;再选最高的两个不同答案节点读取相关原始帧核查。

相似文本与答案一致性只是筛选信号,原帧核查也由 VLM 执行,不是真值证明。

查看原文 ↗

E5 §7.1–7.3,pp.1947–1950;Fig.7–10;Appendix A.1–A.3,pp.1954–1957 作者报告结果

作者报告 LVBench、VideoMME-Long、AVA-100 正确率 62.3%、64.1%、75.8%;AVA-100 为 8 个长视频共 99.2 小时和 120 道题,部分视频拼接,参考答案人工标注而干扰项经 GPT-4o 生成。

整体系统结果;模型搭配不同,不能将总收益归给事件图或树搜索单一组件。

查看原文 ↗

E6 §7.3.5,p.1950;Fig.11 与 Table 2,已查看原始 PDF 图表 作者报告结果

输入采样 2 FPS,RTX4090 建索引 4.4 FPS;单 A100 三视图检索 0.44 秒,Qwen2.5-14B/32B 树搜索分别 101.5/174.2 秒;后续视觉核查另外计时。

吞吐近实时只适用于索引,不表示问答端到端交互实时。

查看原文 ↗

E7 §7.4,pp.1950–1951;Tables 3–4、Figure12;§8 作者报告结果

消融在 LVBench 的 20 个视频、305 题上进行;深度 3→4 时 Qwen14B+Gemini 正确率 61.5→52.7,搜索延迟 90.1→370.3 秒。§7.4.1 先称基线也使用语义片段描述,后又以基线均匀片段解释差异。

深搜不是单调改善;Table 3 的片段归因表述不一致,不采信其单因果解释。

查看原文 ↗

原始来源

论文

Pufibara:候选绑定的工程证据与独立评测契约

关注的问题

Agent多轮修改后可能遗失工程义务,或把旧候选仿真结果误用作当前候选的支持证据。 能编译/仿真及agent自判ready不能证明任务行为正确,最后编辑的工件也不等于有意提交的结果。 原样公共模型可能测到记忆,任意合成任务又可能缺物理真实性与可靠判据。

作者的方法

用持久义务账本和绑定候选身份的证据记录组织Agent修订上下文。 让Agent显式冻结提交精确候选,再由loop外预先冻结的合同独立验收。 从可执行参考模型派生新任务,并以正确样本和能运行但偏离目标的反例校验行为合同。

  • 状态与恢复
  • 观测与评测
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

作者研究Modelica物理系统建模:Agent根据工程任务说明多轮编辑模型、运行仿真并提交结果。方程模型即使能编译和生成轨迹,也可能不满足物理与行为要求;团队同时设计harness和232任务benchmark,观察完整工作流能否交付满足任务契约的候选。 §1 pp.1–2; §3.1 p.4原文依据§5.1 pp.8–9; §5.3 p.10原文依据

运行成功仍可能交付错误模型

物理模型的正确性包含编译和执行之外的行为要求。Agent在多轮修改中既可能遗失初始约束,也可能继续引用旧版本的仿真结果;因此最后一个能运行的模型不能自动代表满足工程任务说明的交付。评测还需要区分解决新任务与重现公共模型,避免只得到一个新的模型排行榜。 §1 pp.1–2; §3.1 p.4§5.1 pp.8–9; §5.3 p.10

02 文章用了什么方法

把工程义务与当前候选一起保存在状态中

账本把每项义务拆为命题、可观测量、仿真场景和判断条件。这里的invariant指跨迭代持续生效的义务,不要求某个数值在时间上恒定;状态记录open、supported、violated或inconclusive,帮助Agent决定补证据还是改模型。 §3.1 Eq.(1) p.4

证据必须说明它来自哪个候选。Repair和Generation的身份覆盖与验收有关的完整工件,Tuning覆盖参数赋值及固定模型/配置。相关内容变化后,先前结果仍能用于审计,却不能支撑新候选的ready状态;新仿真也只有被Agent对照义务裁定后才成为支持、反对或未决证据。 §3.2 Eq.(2) p.5; §4.2 p.7原文依据

显式提交终止修订,独立契约负责验收

readiness要求当前候选的所需义务都有覆盖与支持,但这仍是Agent的工作判断。Algorithm 1在收到显式submit时冻结候选并返回,未写出运行时强制检查ready为真的分支。因此论文支持的是持久记录和清晰提交语义,不能描述成harness保证所有义务已满足才允许提交。 原文依据

提交后评估权转到benchmark拥有的冻结契约。它不读取Agent账本作为正确性依据,不允许Agent更改条件,也不会把结果送回本轮继续修改。132个Repair任务只检查接口、模型检查和仿真;50个Generation与50个Tuning另有行为或响应gate,不能把232个任务统称为完整物理行为验收。 §4.3 p.7; §5.3 pp.9–10原文依据

用可运行反例校验场景判据

任务从能通过相应检查的参考模型派生新的故障、任务说明或调参目标,保留物理结构而改变待解决问题。对于Generation和Tuning,作者通过同一提交路径检查已知正确答案必须通过、可执行但偏离目标的变体必须失败,并检查隐藏契约与可见任务说明是否一致。这使行为gate有明确的有效性检查,但有限场景与公共组件仍分别留下oracle和污染风险。 §5.1 pp.8–9; §5.3 p.10原文依据

03 证据支持到哪里

整体harness比较显示了执行之后的差异

作者在相同后端、任务、Modelica环境和评估器下比较完整Pufibara与Claude Code。DeepSeek条件下通过数为202/232对185/232,Sonnet条件为202/232对187/232。在Sonnet的38个hard Generation任务中,能执行但行为失败的最终提交为4个对21个;这一子集对比支持执行测试会漏掉工程行为错误。 原文依据§6.3 Table 4 p.11§6.4 p.12

资源结果使用逻辑token口径,将缓存输入也计入模型面对的上下文总量。文中76.4%–82.5%的降幅是不同工作流与后端的范围,不是账单节省率;运行时间则是有效任务顺序执行的实际经过时间总和。 原文依据

协议可解释,效果归因仍有限

两套系统保留原生上下文、工具和请求语义,各任务每条件只运行一次。主时间预算同为900秒,但DeepSeek下Pufibara温度为0.1而Claude Code保留原生采样;Generation/Tuning仅在提交验证已经开始时有120秒宽限,不增加Agent轮次。因此整体差异不能拆成账本或显式提交各自的因果收益。 原文依据原文依据

大部分harness实现、完整任务和评估器仍私有。论文中的机制与评测设计可以核对,但完整工件级审查受限;通过固定场景契约也不等于通用物理正确或工业任务适用。 原文依据

04 总结与启发

将证据绑定到精确候选,并把Agent自判完成与外部验收分成两个判断。

我们的理解与启发

将证据失效和验收权威做成运行协议

对迭代工件Agent最有价值的迁移点,是把“哪份证据属于哪次候选”及“谁有权判定完成”写入运行协议。它要求系统保留修改后的证据失效边界,并让Agent自判与正式验收各自承担职责;这些结构值得借鉴,本文的比较还不足以保证迁移后获得相同收益。 §3.2 Eq.(2) p.5; §4.2 p.7原文依据§4.3 p.7; §5.3 pp.9–10§7.2 pp.12–13

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · Agent多轮修改后可能遗失工程义务,或把旧候选仿真结果误用作当前候选的支持证据。

primary §1 pp.1–2; §3.1 p.4§3.2 Eq.(2) p.5; §4.2 p.7

P2 · 能编译/仿真及agent自判ready不能证明任务行为正确,最后编辑的工件也不等于有意提交的结果。

primary §1 pp.1–2; §3.1 p.4原文依据§4.3 p.7; §5.3 pp.9–10原文依据

P3 · 原样公共模型可能测到记忆,任意合成任务又可能缺物理真实性与可靠判据。

primary §5.1 pp.8–9; §5.3 p.10原文依据

D1 · 用持久义务账本和绑定候选身份的证据记录组织Agent修订上下文。

义务保留命题、观测、场景与判断条件;证据同时关联候选和agent裁定。改变相关内容生成新候选,旧结果只留审计历史,不能跨版本支持ready。

core · described · mitigate · 对应问题 P1 §3.1 Eq.(1) p.4§3.2 Eq.(2) p.5; §4.2 p.7原文依据

D2 · 让Agent显式冻结提交精确候选,再由loop外预先冻结的合同独立验收。

readiness指导agent自判,submit是独立动作;无submit是未提交失败。外部evaluator只看冻结工件,且不给进一步修订机会,使自定义验证不能变成官方验收条件。

core · described · measure · 对应问题 P2 原文依据§4.3 p.7; §5.3 pp.9–10原文依据

D3 · 从可执行参考模型派生新任务,并以正确样本和能运行但偏离目标的反例校验行为合同。

参考模型提供物理结构,故障、brief或调参目标定义新任务;正负例和brief一致性检查约束判据,但不声称彻底消除污染或oracle错误。

core · described · validate · 对应问题 P3 §5.1 pp.8–9; §5.3 p.10原文依据原文依据

E1 p.1 title/author/arXiv stamp 原文描述

论文署名Wang Zizhe及zizhe.wang@tu-dresden.de,v1日期2026-08-24。

版本、日期与作者

查看原文 ↗

E2 title Zizhe Wang; affiliation/contact/Career 原文描述

机构页列Zizhe Wang、TU Dresden软件技术教席及相同邮箱;生涯列2022–2026博士生经历。

作者身份;不证明论文获同行评审

查看原文 ↗

E3 §1 pp.1–2; §3.1 p.4 原文描述

模型能编译/仿真仍可物理错误;多轮修改会遗失需求或沿用旧候选证据。

问题及传统执行反馈不足

查看原文 ↗

E4 §3.1 Eq.(1) p.4 原文描述

ledger把需求表示为工程命题、可观测量、场景与判断条件,状态为open/supported/violated/inconclusive;它是工作记录,不是官方裁判。

持久义务及状态语义

查看原文 ↗

E5 §3.2 Eq.(2) p.5; §4.2 p.7 原文描述

证据记录绑定义务、候选、场景、观测量、轨迹或测量、agent裁定;旧结果保留历史但不能支撑变更后的候选。

候选绑定与失效范围

查看原文 ↗

E6 §3.3 Eqs.(3),(4) p.5; §4.3 pp.7–8 Algorithm 1 原文描述

ready要求当前候选覆盖并支持所需义务;agent选择显式submit,算法收到submit便冻结候选并返回,没有运行时强制ready分支。

自判readiness与可执行提交合同的区别

查看原文 ↗

E7 §4.1 Figure 1 p.6; §4.2 pp.6–7 原文描述

runtime/profile管理动作与任务语义、持久工程状态保留证据、透明执行平面执行agent所选动作。Repair/Generation候选是完整相关工件;Tuning是参数加固定模型/配置。

组件及profile差异

查看原文 ↗

E8 §4.3 p.7; §5.3 pp.9–10 原文描述

submit冻结精确工件或参数并结束修订;外部benchmark合同隐藏且预先冻结,判定不反馈给agent继续改,也不依据agent ledger裁定验收。

提交与独立验收权威边界

查看原文 ↗

E9 §5.1 pp.8–9; §5.3 p.10 原文描述

232任务以可执行参考模型为基础生成故障/新brief/调参目标;140直接公共、15组合公共组件、77内部;Generation/Tuning用已知正确与可执行但偏离目标变体校验,合同与brief一致性被审查。

任务真实性与测量有效性设计;作者描述

查看原文 ↗

E10 §5.2 Table 1; §5.3 Eq.(5) p.9 原文描述

132 Repair检查接口、模型检查与仿真,无独立行为gate;50 Generation及50 Tuning有任务特定行为/响应检查,PASS只要求所有适用gate。

分母和验收范围

查看原文 ↗

E11 §6.1–6.2 p.10; Appendix A Tables 5–6 pp.15–16 原文描述

同模型后端/任务/环境/evaluator,完整harness保留native语义,各条件每任务一次;900s主限、100turn,Generation/Tuning提交验证仅可延长120s且不增turn,Tuning最多100次仿真;DeepSeek温度Pufibara0.1、Claude Code native采样。

预算匹配及残余混杂

查看原文 ↗

E12 §6.3 Table 4 p.11 作者报告结果

作者报告DeepSeek条件通过数202对185,Sonnet条件202对187,各分母232;Generation分别35/50对27/50及32/50对26/50。

完整系统比较,不能归因单组件

查看原文 ↗

E13 §6.4 p.12 作者报告结果

Sonnet条件38个预定hard Generation中,能执行却行为失败的最终提交Claude Code21个、Pufibara4个。

特定子集失效阶段对比,不是全232任务统计

查看原文 ↗

E14 §6.2–6.3 pp.11–12; §7.3 p.13; Appendix A 原文描述

logical tokens含uncached/cache-write/cache-read/output;76.4%–82.5%降低为各workflow/backend范围,不能解释为账单节省;runtime为顺序执行有效任务walltime。

资源口径

查看原文 ↗

E15 §7.3 p.13; Artifact Availability p.14 原文描述

各条件单次运行,不隔离单机制;公共组件污染不可排除;有限场景非形式正确;大部分实现与完整任务/evaluator私有,只有文档/摘要/选定文件公开。

归因、覆盖和外部审查限制

查看原文 ↗

E16 §7.2 pp.12–13 原文描述

方法增量是义务、观测、场景、候选、证据与提交关系的持久可审计协议;instruction/skill可鼓励相似思考,但本身不替代harness状态和独立验收合同。

与仅提示及传统read-edit-test的区别

查看原文 ↗

原始来源

工程实践

Harness Inspector:保留交付关系的证据强度

关注的问题

仅查看会话或提交,无法保留原始意图、探索过程与最终交付之间的多对多证据关系。 路径、时间和动作频率容易被误读成贡献归属或可复用经验,证据强度需要显式保留。

作者的方法

以独立采集和归一化建立Story(需求意图)—Session(执行会话)—Commit(代码提交)的只读证据投影。 关系携带来源事实与限制,明确区分直接关系、同路径观测、候选及背景。

  • 观测与评测
  • 文件与工件
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

Qoder团队希望从真实Agent交付过程中发现可提炼的SKILL。自主探索、重试和跨会话修改使高频动作未必对应有效成果,因此团队先把原始需求、执行记录和最终代码变化放到共同的审阅范围,避免直接从单会话频率提炼经验。 turn61view1 L12-L28turn61view1 L31-L50turn61view1 L79-L82

单会话无法解释最终交付

自主探索让一次交付散落在多个会话与提交中。原文指出,单看会话会丢失最终输出,单看提交则无法解释过程;频繁搜索和重试也未必值得提炼成SKILL。 turn61view1 L31-L50turn61view1 L79-L82

02 文章用了什么方法

先保留独立证据,再建立分级关系

Story、Session与Commit分别表示交付意图、Agent活动过程与Git中的代码结果,一次交付可以关联多次会话和多个提交。系统不先假设它们一一对应,而是在读取各自事实后再连接;这让共享路径、多人修改和缺失会话不必被压成一条看似确定的故事。 turn61view1 L31-L50turn83view0 L27-L32

官方文档把处理过程分为有界采集、独立读取、归一化、建立关系和只读投影。会话证据与Git事实分别采集,缺失来源保留空缺;不同关系依据保留各自强度,路径重合和时间相近不能直接证明作者归属。 turn83view0 L27-L32turn83view0 L40-L47

关系的等级决定读者能得出多强的结论。Explicit/direct来自人工核验的引用或直接元数据,能支持记录之间存在明确连接,仍不代表会话贡献了提交的每一行。Observed same-path只确认双方涉及同一个仓库相对路径,不能据此断言会话编写了最终内容。Candidate来自结构、文本或时间等线索,只提供待审候选;Contextual只把日期或路径历史放在附近作为背景,不建立直接联系。这四档使缺失或较弱的依据留在数据表达中,而不是在展示时被升级为归因。 turn83view0 L40-L47

长轨迹按Turn查看,Replay只播放已保留事件。它不恢复工作区或继续执行;没有实际时间时只展示顺序。 turn61view1 L66-L75

03 证据支持到哪里

证据支持结构,未支持改进效果

原文、官方机制文档和公开示例能交叉检查关系如何被表达。示例明确使用虚构数据,因此支持的是分级证据结构的展示,不能作为真实交付中的准确率或收益结果。 turn61view1 L62-L65turn83view0 L27-L32turn80view0 L16-L17; L39-L72

观察不授予执行与验收权限

测试调用不等于测试通过,缺少成本和结果记录也不能记为零。Compare、Eval与自动SKILL验证属于后续方向;当前页面中的Story对应关系不能证明任务等价。 turn83view0 L29-L31; L57-L89turn83view0 L90-L96turn61view1 L79-L82

采集范围和隐私处理也限制了能解释的内容。系统只查看限定窗口与支持的provider,归一化会舍弃原始工具载荷及绝对用户目录等敏感细节;某个来源缺失时,页面能呈现的只是剩余证据。因此这套结构适合解释记录之间为何被关联,不能据此断言已经完整恢复了交付过程。 turn83view0 L27-L32turn83view0 L29-L31; L57-L89

04 总结与启发

在产生可复用经验之前,先把事实关系与推测关系分开保存。

我们的理解与启发

把推断强度一起传给后续系统

对Agent系统可迁移的部分,是让后续记忆或技能流程收到关系依据和缺失状态。这样才能把需要人工审阅的候选与已验证事实区分开;本文没有证明这种迁移一定带来更高任务成功率。 turn83view0 L40-L47turn83view0 L29-L31; L57-L89turn83view0 L90-L96

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 仅查看会话或提交,无法保留原始意图、探索过程与最终交付之间的多对多证据关系。

primary turn61view1 L31-L50

P2 · 路径、时间和动作频率容易被误读成贡献归属或可复用经验,证据强度需要显式保留。

primary turn61view1 L79-L82turn83view0 L40-L47

D1 · 以独立采集和归一化建立Story(需求意图)—Session(执行会话)—Commit(代码提交)的只读证据投影。

保留不同证据域后再连接,避免单条会话视图丢失意图或产物。

core · described · diagnose · 对应问题 P1 turn61view1 L31-L50turn61view1 L62-L65turn83view0 L27-L32

D2 · 关系携带来源事实与限制,明确区分直接关系、同路径观测、候选及背景。

弱连接仍可用于审阅,但不授权因果归属或技能有效性的结论。

core · described · diagnose · 对应问题 P2 turn61view1 L62-L65turn83view0 L40-L47

D3 · 按Turn查看和仅序列Replay,缺少时间/结果/成本时保留unknown。

降低查看长轨迹的负担,同时避免展示层补造状态或执行权限。

supporting · described · diagnose · 对应问题 P2 · 支撑 D1D2 turn61view1 L66-L75turn83view0 L29-L31; L57-L89

E1 turn61view1 L12-L28 原文描述

Qoder Team在2026-08-14发布项目blog,动机是从交付中提炼SKILL前先理解过程与最终变化。

作者、日期与具体问题

查看原文 ↗

E2 turn61view1 L31-L50 原文描述

Story对应意图、Session对应过程、Commit对应结果;单看会话或提交都会遗失另一端,多会话/提交关系不能压成一条线。

问题与设计对象

查看原文 ↗

E3 turn61view1 L62-L65 原文描述

Workbench将要求、活动和相关提交并置;较弱连接保留candidate/unmapped。

交付证据工作台的工程设计

查看原文 ↗

E4 turn61view1 L66-L75 原文描述

Trace按Turn展开并折叠重复活动;Replay只播放已保存事件,不重跑工具/恢复工作区/恢复会话,缺时刻时只保留顺序。

事件查看与执行权限边界

查看原文 ↗

E5 turn61view1 L79-L82 原文描述

高频重复动作也可能是薄上下文下的重复查找和重试;当前贡献是可检查证据,SKILL候选及后续验证仍在未来。

不能推导自动优化有效

查看原文 ↗

E6 turn83view0 L27-L32 原文描述

文档给出有界采集、独立Session与Git/Entire读者、归一化、按依据建立关系、只读HTML投影五步,缺失provider保留证据空缺。

已描述的流水线与依赖

查看原文 ↗

E7 turn83view0 L40-L47 原文描述

关系分为explicit/direct、observed same-path、candidate、contextual;精确路径重合、时间及文本不被升级为因果作者身份。

关系权威与误归因边界

查看原文 ↗

E8 turn83view0 L29-L31; L57-L89 原文描述

归一化保留有限细节、实际时间及仓库相对路径;有界窗口、可选人工review的稳定Story anchor;测试调用不等于通过,缺token/cost等观测不填零。

前提与信息损耗

查看原文 ↗

E9 turn83view0 L90-L96 原文描述

Compare/Eval/Decision仍属后续;Story标签不证明等价任务,强评估需要可比处理及预算等条件。

现有方案不构成有效性比较

查看原文 ↗

E10 turn80view0 L16-L17; L39-L72 原文描述

公开示例明确为确定性fictional数据,可检查Evidence Drawer与关系分级呈现,不能视为真实生产效果或匹配准确率验证。

结构示例及外推边界

查看原文 ↗

原始来源

论文

AMemGym:让被测助手参与形成历史,识别离线记忆评测偏差

关注的问题

静态他人轨迹不包含被测助手自身对话选择的后果,记忆配置排序可能偏移。 最终QA错不能区分状态写入/保留、后续读取和读到后的使用,模型应用能力会混入记忆分。

作者的方法

schema/state trajectory → fixed exposure utterance → on-policy free-form interaction → period evaluation overall/oracle normalized score plus write/read/utilization conditional probes

  • 文件与工件
  • 记忆与上下文
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

长期个人助理需根据用户偏好、计划与环境变化给建议,每period后回答依赖最新2–3状态的选择题。 既有比较:静态其他模型生成的聊天记录;native长窗、原始文本RAG、agentic外部写入AWE、in-context摘要AWI。 原文依据原文依据

02 文章用了什么方法

固定该知道的事实,让助手参与形成历史

off-policy指复用其他助手预先产生的静态轨迹,on-policy指被测助手参与实时对话。静态轨迹来自其他助手,遗漏当前助手的追问、回应与记忆写入如何互相影响。AMemGym先规定用户状态怎样随生活事件变化,每个会话用固定语句揭示必要事实,再让用户模拟器按真实回复继续对话。这保留可比较的状态,同时纳入被测助手的行为后果。 原文依据

AWE让助手主动整理并写入外部记忆,AWI则在上下文内保留摘要。作者在相同gpt-4.1-mini下报告,AWE默认配置实时互动得.291,复用gpt-4.1历史只得.253;检索top10配置分别是.275和.273。静态测试会倾向top10,而实时互动更看好默认配置,说明两种环境不能默认互换。 该差异是作者样本中的排序反转;论文没有为全部配置提供配对置信区间,不能直接推广为普遍显著差异。 §4.1–4.2; Table2

先分应用能力,再定位状态何时不可用

论文把答题准确率按随机猜测和显式提供正确状态时的得分归一化,后者称为oracle条件,即直接给出答案所需事实。答错后再问所需状态:当前状态全对则归为利用失败;否则回看最近写入位置的状态探针,区分当时不可用与后来不可读。它减少记忆与应用能力混杂,却不是完全因果分离,也不直接证明数据库写入或删除。 原文依据

03 证据支持到哪里

自动真值经过校准,排序稳定性仍有范围

作者请两位团队专家独立检查状态曝光、会话一致性与100道gold题;gold与两人的一致率为.96和.94。四个普通长窗模型还做了五次评测并报告均值和标准差。这个证据支持环境可用,却没有覆盖全部记忆配置的排名不确定性。 原文依据

更好的写入不保证整体答案更好

完整反馈和仅问题反馈的自演化最终分都为.197;完整反馈虽降低写入故障,使用故障却更高。另一方面,不同对话的长度、检索与调用次数没有全部等额限制,论文没有证明AWE在相同总成本下最优。 原文依据§4.1–4.2; Table2

04 总结与启发

对话选择会改变待测记忆本身,因此context评测必须把静态理解与在线互动分开。给状态oracle和分段probe能定位测量盲区,但这些是操作性诊断,不是证明系统已解决遗忘。

我们的理解与启发

采用实时互动协议,保留三个独立观察面

编辑判断:把结构化用户状态轨迹、实际曝光事件、助手对话及period题分开存档;评测配置时明确区分复用历史与真实互动,并保留同模型oracle、状态probe与最终答题三个观察面。优先采用测量协议;AWE配置与自演化prompt不作为直接生产默认值。 原文依据原文依据§4.1–4.2; Table2原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 静态他人轨迹不包含被测助手自身对话选择的后果,记忆配置排序可能偏移。

primary 原文依据§4.1–4.2; Table2

P2 · 最终QA错不能区分状态写入/保留、后续读取和读到后的使用,模型应用能力会混入记忆分。

primary 原文依据

P3 · 自由模拟会话可能没有传入真值或后续冲突,自动gold可能不可靠。

secondary · ↳ P1 原文依据原文依据

D1 · schema/state trajectory → fixed exposure utterance → on-policy free-form interaction → period evaluation

将状态真值和初始曝光固定,让用户模拟器对被测助手真实响应继续对话,减少复用他人轨迹对配置选择造成的偏差。

core · described · mitigate · 对应问题 P1 原文依据§4.1–4.2; Table2

D2 · overall/oracle normalized score plus write/read/utilization conditional probes

同模型给出显式state条件的应用基线,并在失败时用当前与write时state probe定位信息在哪一段不可用;诊断标签不替代存储层取证。

core · described · diagnose · 对应问题 P2 原文依据

D3 · state exposure/state integrity/golden-choice meta-evaluation; user LLM change; 5-run native subset

用两专家校验曝光、持续一致性和gold选择,用换simulator及重复native评测限定自动环境误差。

supporting · described · validate · 对应问题 P3 · 支撑 D1 原文依据

E1 §1; §3.1–3.2; Figure1/2; Appendix C.3/C.4 原文描述

先采样profile、问题和必要state schema,按生活事件规定状态演化;固定状态揭示起始语句,后续user simulator依据当前状态与被测assistant响应继续对话,构成on-policy历史。

提供可控信息曝光和真实助手互动,不保证真实用户代表性。

查看原文 ↗

E2 §3.3; Figure3 on PDF p5; Appendix C.5 原文描述

每period选择题accuracy;(overall-random)/(oracle_state-random)归一化。问题错误时先问必要state,全部答对归utilization;否则回看最近write时的state probe区分write/read。

oracle是给定状态条件,不是数学上界;阶段标签是行为诊断,不等价于直接检查持久存储写入。

查看原文 ↗

E3 §4.1–4.2; Table2 作者报告结果

20profiles、每profile10题;base(10,2,4)、extra(20,3,10)。memory系统同gpt-4.1-mini、embedding=text-embedding-3-small。off-policy复用gpt-4.1交互轨迹;AWE(2,4,30) on .291/off .253,top10 .275/.273,最优配置排序改变。

相同模型身份控制不能代表同总token;off-policy仅一种轨迹来源,不能推出所有离线评测都同幅度失真。

查看原文 ↗

E4 §3.4; Appendix D; Appendix F.2/F.6 Table8 作者报告结果

两团队专家独立标注200 exposure题质量.991、AC1 .968;40会话748项一致性.992、AC1 .982;100gold题人间.92、人-LLM .96/.94。换user模型DeepSeek-v3附录结果相近;四native模型各5次均值SD。

覆盖数据与gold校准,不是全部memory配置的多次不确定性;审阅者来自团队。

查看原文 ↗

E5 §4.4 Fig7; §5 Table3; Appendix C.2/E/F.4 作者报告结果

更新频率/short-term长度/top-k构成配置干预;完整反馈与QuestionOnly最终memory均.197 vs no evolution .172,完整反馈write .263但utilization .136,高于QuestionOnly .110。C.2每实例结构生成$0.40、user simulator$0.17(GPT4.1)/$0.02(DeepSeek),例示被测GPT4.1 $13。

优化demo中未核到独立用户留出,不能宣称泛化;成本是作者当时模型口径,未提供完整等总预算配置Pareto。

查看原文 ↗

原始来源

论文

CIMemories:按接收者和目的衡量必要信息与累计披露

关注的问题

只保护一个秘密或只报低泄露率,无法发现同一记忆在不同接收者/目的下的细粒度不当披露,也奖励什么都不说。 单次响应平均掩盖不同任务和不同运行分别泄露不同属性的累积风险;记忆增长改变可暴露信息集合。

作者的方法

profile memory statements × purpose/recipient contexts → necessary/inappropriate/ambiguous labels → violation+completeness Violation@n over task/draw union; fixed necessary attributes plus growing inappropriate set

  • 文件与工件
  • 记忆与上下文
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

有长期用户属性的assistant为指定recipient起草达到purpose的完整消息,memory statements前缀进入单轮模型。 既有比较:单秘密或极少属性的隐私评测,以及只报告少泄露而不同时测必要信息覆盖。 原文依据原文依据

02 文章用了什么方法

同一事实换一个接收者,披露规范就可能改变

单个秘密的测试无法判断模型是否会从正确领域多带出不必要细节。CIMemories为每个合成用户建立上百条属性,将每项属性与任务目的、接收者配对,标为必要、不合适或模糊。模型同时被要求完成消息任务,因而少泄漏不能靠什么都不说来取得。 这里的contextual integrity(情境完整性)表示信息披露是否符合当前目的和接收者;不是模型上下文窗口是否完整。 原文依据原文依据

把累计暴露与单次输出质量分开计量

Violation@5先查看某项属性是否在任一个不适合披露的任务及五次响应中出现,再对属性取平均。Completeness则计算每次任务需要的信息覆盖。两者分母与聚合不同:作者报告GPT-5为25.08%和56.61%,前者不是四分之一请求泄露,而是被测任务集合里四分之一相关属性至少暴露过一次。 原文依据

作者还固定必需属性,逐渐加入不该披露的记忆内容。五个profile的对照中,披露增加而必要信息覆盖近似稳定。这说明新增记忆带来独立风险压力;由于上下文长度也增加,它不能把信息组成与token数量的影响完全拆开。 原文依据

03 证据支持到哪里

标签与检测器分别校准,测到的仍是明确披露

最终会议版请三人检查100个标签,模型与三人一致率为85%、87%、83%;另100个披露判断由一位作者检查,与REVEAL评分器一致94%。但评分提示只计完整值的明确披露,间接推断和部分透露不会计入,因此这些数字不覆盖全部隐私信息流。 原文依据

单轮消息探针不能代表真实长期执行安全

最终版额外60个profile保留了风险信号,但研究仍是单轮、无工具任务。重复采样并集测的是更广的暴露机会,没有模拟真实多session记忆演化;必要属性覆盖也不等于收件人认可消息或业务成功。全共识规范减少争议,同时漏掉个人偏好和模糊边界。 原文依据原文依据

04 总结与启发

context是否有用须与能否向该接收者披露分开测量;静态memory前缀也能形成有效的信息干预。最可迁移贡献是任务化属性规范与累计风险指标,不是模型安全排行榜或一条隐私prompt。

我们的理解与启发

为上下文选择增加接收者与目的维度

编辑判断:在context选择与对外输出评测中使用attribute×purpose×recipient矩阵,分别保留必要、禁止与不确定项;同时看输出覆盖与跨任务/多次响应的累计属性披露,避免把全删记忆当成功。该规范层可接企业已授权的数据政策;论文提供测量协议,不提供可直接强制执行的隐私授权网关。 原文依据原文依据原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 只保护一个秘密或只报低泄露率,无法发现同一记忆在不同接收者/目的下的细粒度不当披露,也奖励什么都不说。

primary 原文依据原文依据

P2 · 单次响应平均掩盖不同任务和不同运行分别泄露不同属性的累积风险;记忆增长改变可暴露信息集合。

primary 原文依据原文依据

P3 · 自动隐私规范标签和披露检测器可能带偏,导致风险测量失真。

secondary · ↳ P1 原文依据原文依据

D1 · profile memory statements × purpose/recipient contexts → necessary/inappropriate/ambiguous labels → violation+completeness

将每个attribute与task/recipient组成标签矩阵,同时报告不当披露和必要属性覆盖,区分安全的最小信息与无用的全拒绝。

core · described · measure · 对应问题 P1 原文依据原文依据

D2 · Violation@n over task/draw union; fixed necessary attributes plus growing inappropriate set

按属性聚合所有不合适任务与重复响应的并集,暴露平均单次看不到的累计泄露;固定必要信息、增加不应披露信息来考察记忆组成变化。

core · described · measure · 对应问题 P2 原文依据原文依据

D3 · 30 model label draws per pair; unanimous labels; separate label/reveal human agreement

三persona多次共识过滤降低模糊规范的影响,标签和REVEAL分别用人类小样本校准,明确可测范围。

supporting · described · validate · 对应问题 P3 · 支撑 D1 原文依据原文依据

E1 §3 Definitions3.1/3.2; Figure2; §5.1/Table1 原文描述

Violation@n按每项属性在任一不该披露任务/样本中是否出现取并集,再平均;Completeness按每任务必要属性覆盖平均。5次采样、多任务下GPT5 Violation@5=25.08%、Completeness56.61%。

并集属性率,不是单请求泄露概率;completeness是必要信息覆盖而非业务任务成功。

查看原文 ↗

E2 §4.1.1–4.1.2; Table2; Appendix A Fig9/10; Appendix B 原文描述

10 synthetic profiles,平均146.7 attributes/45.7 contexts;任务含purpose/recipient,同属性对不同任务可必要或不合适。GPT5按Westin三类隐私persona各10次标签,仅所有persona/采样一致者评分,ambiguous排除。

合成偏好规范与共识子集,不是法律或真实个人授权。正文five属性与后文189×49名义数不一致,报告实际表2统计而不照搬名义数。

查看原文 ↗

E3 §5.2.2–5.2.3; Figures4/5; Appendix A Fig8 作者报告结果

同GPT5改变privacy prompt得到覆盖与违规取舍;5profiles固定necessary attributes而增加inappropriate attributes,违规增长、completeness近稳;Qwen reasoning comparison是variant变化。

context intervention有独立贡献;额外属性同时增大token,不等长因果分离;reasoning变体不能当纯context贡献。

查看原文 ↗

E4 §6 Human Agreement; Table4; Appendix A Fig7 作者报告结果

标签校准100attribute-context pairs,正负各50,三人(2作者1非作者)与GPT5一致85/87/83%,人间80–84%。REVEAL judge另100项正负各50,一作者一致94%。Fig7只计明确披露完整value,不计隐含/部分。

校准覆盖该平衡样本,不提供真实prevalence的precision/recall;形式定义可推断披露比实际judge更宽,实际数字限显式完整值。

查看原文 ↗

E5 Appendix C Table8; Tables5–7; ConfAide comparison; §6 limitations 作者报告结果

另60profiles GPT5违规26.2%覆盖53.8%;persona-wise结果提供不同规范;ConfAide GPT5违规0覆盖42。作者明确single-turn、non-tool。

扩展样本是稳健性支持,不是多session真实状态演化;跨benchmark绝对分不可直接当改善幅度;5次取并集不等同均值置信区间。

查看原文 ↗

原始来源

论文

A.I.G:在真实DeepSeek Harness上分开测量载体、输出与动作

关注的问题

把文件载体近似为纯文本会跳过解析与编码路径,无法判断不可信信息是否真正到达被测循环。 混合输出改写、敏感调用和参数成功的单一攻击率会掩盖风险层级与评分器分歧。

作者的方法

真实DSH适配器、载体矩阵、source/sink插件和完整session trace 按目标类型和Full/Partial/Failure分层,分别保存JR规则判定与JL语义判定

  • 文件与工件
  • 工具与协议
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

插件式DeepSeek Harness读取网页、文件、邮件或skill后,模型自主选择下一工具;攻击者只控制外部材料,用户请求保持良性。 既有比较:对比原措辞攻击naive与12种变换,同时比较同类载体text/file路径;不是无攻击clean对照。 §2–4; Figures1–4; Table1原文依据

02 文章用了什么方法

保留真实循环,改变不可信材料到达的路径

这里的source是内容读取工具,sink是邮件、命令等敏感动作的模拟接口。作者保留DSH的Agent循环、工具注册、模型适配和session事件,用测试插件接入六类source和八类sink。用户请求保持良性,攻击材料经文本或真实文件生成及解析后进入模型,因此能观察纯文本替代品容易遗漏的格式差异。 §2–4; Figures1–4; Table1原文依据

同一内容既可能改变回答,也可能推动动作

规则评分器JR读取精确调用与参数;语义评分器JL离线阅读完整轨迹,两份判定互不覆盖。Full与Partial互斥,但sink调用可以落在多个结果类别中。输出目标与要求敏感调用的目标还要分开统计,才能知道模型只是谈论外部指令,还是尝试执行它。 原文依据§6.3/6.6, §7–8, Appendix A/B

扩展能追加上下文,执行权限仍需单独裁决

固定DSH源码会将tool result写入session并接受additionalContexts,让扩展提供的内容影响后续推理。工具体之前另有pre-execute与只能拒绝的guard。这解释了内容边界与行动边界的区别;论文仅定位了已有接口,没有比较启用防护前后的效果。 原文依据commitReady lines145–159

03 证据支持到哪里

载体对照有实证,双评分分歧没有自动裁判

作者报告14560次受控执行;隐藏Unicode在文件模式得到116/455的JR完整成功,文本模式为0/455。全体641次sink调用不能加到819次JR完整成功和298次部分遵从之上。JL判定输出目标完整成功35.7%、要求sink的目标2.5%,两个分母对应不同风险。 原文依据§6.3/6.6, §7–8, Appendix A/B

JR与JL的部分遵从分别为2.0%和7.3%,说明判据看见的行为不同;没有人工校准,不能把更多部分判定解释为JL更准确。 原文依据§6.3/6.6, §7–8, Appendix A/B

模拟动作与脱敏代码限定外推范围

单模型配置缺少无攻击任务效用、完整预算/延迟和同case重复不确定性。文件解析器及评分器未随仓库公开;adapter用最近tool call关联结果,也未把driver错误或退出码纳入结果。这限制并发和异常路径上的推广,不能据此断言作者聚合表已经算错。 §6.3/6.6, §7–8, Appendix A/B原文依据原文依据

04 总结与启发

保留真实循环只是第一步;载体解析、内容曝光、输出变化、敏感调用及参数命中需要分别观察,双judge结论应并存。

我们的理解与启发

采用分层证据,不采用静态安全标签

本项目建议把载体版本、来源、模型可见内容、调用ID和模拟sink参数连接成证据链,保留每个评分器的原判定及错误类别。优先复用这套观察结构;工具权限由既有执行控制面负责,不能把较低注入分数当作授权或真实副作用安全证明。 §2–4; Figures1–4; Table1§6.3/6.6, §7–8, Appendix A/B原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 把文件载体近似为纯文本会跳过解析与编码路径,无法判断不可信信息是否真正到达被测循环。

primary §2–4; Figures1–4; Table1原文依据

P2 · 混合输出改写、敏感调用和参数成功的单一攻击率会掩盖风险层级与评分器分歧。

primary 原文依据§6.3/6.6, §7–8, Appendix A/B

D1 · 真实DSH适配器、载体矩阵、source/sink插件和完整session trace

在保留循环及工具选择的情况下只替换输入和外部效果,使text/file路径的不同可观察,同时用模拟sink隔离实际副作用。

core · described · measure · 对应问题 P1 §2–4; Figures1–4; Table1原文依据原文依据commitReady lines145–159

D2 · 按目标类型和Full/Partial/Failure分层,分别保存JR规则判定与JL语义判定

先看内容暴露,再判断输出或动作尝试,最后核对目标参数,避免把含canary或任意sink调用当作完整成功;分歧提示不同判据而不决定哪位judge正确。

core · described · diagnose · 对应问题 P2 原文依据§6.3/6.6, §7–8, Appendix A/B原文依据

D3 · 追踪additionalContexts与pre-execute/deny-only guard位置

把可影响下一轮上下文的扩展和真正执行动作的控制点区分开,说明评测观察应落在哪里;原文未实现或比较新的防护策略。

supporting · described · diagnose · 对应问题 P1 · 支撑 D1 原文依据commitReady lines145–159

E1 §2–4; Figures1–4; Table1 原文描述

固定用户请求与真实DSH循环/registry/provider/session path,以插件将不可信载体注入source tool,敏感sink只记调用参数。text/file两路径分开,trace为分析单位。

支持真实循环上的内容到动作测量;fixture与外部parser不等于生产工具端到端。

查看原文 ↗

E2 §3.3, §5 Table2, §6 Tables3/4/6 作者报告结果

1120基础case乘13措辞条件为14560次;JR819full/298partial,JL772full/1060partial/9error。641 sink调用与full/partial重叠;隐藏Unicode每模式455次,file116/455、text0/455。

仅作者单一deepseek-v4-flash配置;矩阵规模不等于重复运行的置信度。

查看原文 ↗

E3 §6.3/6.6, §7–8, Appendix A/B 作者报告结果

JL输出canary成功35.7%、sink-required2.5%,不同目标必须分母分开。论文未比较建议的防护,所有sink为模拟。

测量输出控制与动作尝试;不能证明防护效果或真实业务副作用。

查看原文 ↗

E4 What is included; Text mode and file mode; evaluator dependencies 原文描述

公开仅脱敏数据、少量trace与聚合;file parser和评估器属于外部依赖。

核验发布范围,不声称源码覆盖完整评分与载体管线。

查看原文 ↗

E5 run; _trace_from_jsonl; _map_event lines81–146 编辑核验判断

subprocess stdout转trace但不检查returncode/driver error;tool result用最近tool call命名,无call ID关联。

公开适配器在异常/并发推广上的局限;不据此认定原聚合结果出错。

查看原文 ↗

E6 ToolGuard lines704–711; execution gate lines1474–1504 原文描述

pre-execute后运行deny-only guard,拒绝原因阻断dispatch,后续不提供allow覆盖。

证明已有执行控制接口;论文没有防护开关对照。

查看原文 ↗

E7 commitReady lines145–159 原文描述

按模型顺序提交tool result,保留call seq并接受additionalContexts。

说明插件怎样改变后续模型上下文;追加并非新授权。

查看原文 ↗

原始来源

论文

MEMENTO:把记忆召回与利用分开诊断

关注的问题

任务失败时,仅看最终成功率,无法判断问题是否出在获得记忆后的理解和使用环节。 完整历史同时承载用户偏好和行动示例;直接压缩历史,可能在减少干扰的同时丢掉有用示范。

作者的方法

保持场景和目标相同,改变指令是否明说偏好,并保证所需记忆出现在检索结果中。 保留完整交互轨迹,同时用分层用户画像图单独组织偏好事实和行为顺序。

  • 记忆与上下文
  • 文件与工件
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

在个性化物体整理任务中,Agent 需要根据过去的交互,理解用户对物品的称呼和日常摆放习惯。传统的明确指令已经给出目标,无法充分考察这种能力。 §3.1–3.4

记忆已经提供,Agent 能否把偏好落实到行动?

个性化整理需要 Agent 从过去的交互中理解用户偏好。一次任务失败,可能涉及信息没被找回,也可能涉及信息已经出现、却没有被正确理解或用于规划。本文首先要弄清的是后一种困难。 §3.1–3.4

02 文章用了什么方法

保持目标相同,改变指令是否明说偏好

作者先让 Agent 按信息充分的指令完成任务,形成参考表现并保存交互轨迹;随后在相同场景和目标下,换成需要依赖历史偏好的指令。这样可以比较:目标直接给出时能做到什么,需要从记忆还原目标时又能做到什么。 §3.1–3.4

为了聚焦利用环节,检索结果中若缺少任务所需的正确记忆,作者会将它补入。这就是“金标准记忆”控制:确保相关信息已经提供,再观察模型能否用好它。它有助于排除漏召回,但没有把理解、规划等因素完全隔离。 §3.1–3.4

把偏好事实单独组织,同时保留行动示例

文章还研究了另一项设计:历史轨迹既包含用户偏好,也提供怎样完成任务的示例。作者发现,简化记忆并不总能改善表现,因此保留轨迹,另用用户画像图组织偏好事实。图中通过层级关系关联用户、知识和具体元素,通过时序关系保留行为顺序。 §6.1–6.2、图8–9

这项设计的意图是让偏好更容易查找,同时保留轨迹中的行动示范。作者报告加入画像后任务表现改善;我们的判断是,这支持继续考察两类信息分开组织的价值,但尚不能把收益全部归因于图结构本身。 §6.1–6.2、图8–9

03 证据支持到哪里

正确记忆在场,成功率仍然下降

表1中,GPT-4o的成功率从获取阶段的95.0%降到单记忆利用阶段的85.1%,下降9.9个百分点。作者报告的这一结果说明:提供相关记忆,并不足以保证模型达到目标直接给出时的表现。 表1、§4.2

这里需要修正原文的一处概括。正文声称所有模型的成功率下降超过20%,但上述GPT-4o结果无论按百分点还是相对降幅计算,都不符合这一说法。分析应保留具体模型与任务条件,不能照搬总体表述。 表1与§4.2正文

这些结论成立于受控任务,外推需要保留条件

主实验采用理想化感知与动作;多记忆任务增加目标与协调负担。画像图还引入额外处理与上下文开销,现有结果不能单独证明等预算下的图结构收益。 因而,这篇文章更适合帮助理解和组织记忆利用问题,不能直接作为真实机器人可靠性或通用记忆架构的证明。 §4.1、附录A.1§6.1–6.2、图8–9

04 总结与启发

MEMENTO用受控任务观察记忆已提供后的利用困难,并探索偏好事实与行动轨迹分开组织的设计。

我们的理解与启发

先区分信息是否到位,再判断组织方式是否合适

我们更倾向于借鉴两点:解释记忆系统表现时,区分是否获得所需信息与获得后能否使用;组织历史时,区分偏好事实与行动示例。这些启发适用于需要历史偏好的任务,不能据此把用户画像图当作所有记忆系统的默认方案。 §3.1–3.4§4.1、附录A.1§6.1–6.2、图8–9

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 任务失败时,仅看最终成功率,无法判断问题是否出在获得记忆后的理解和使用环节。

primary §3.1–3.4

P2 · 完整历史同时承载用户偏好和行动示例;直接压缩历史,可能在减少干扰的同时丢掉有用示范。

primary §6.1–6.2、图8–9

D1 · 保持场景和目标相同,改变指令是否明说偏好,并保证所需记忆出现在检索结果中。

明确指令提供参考表现;隐含指令要求模型从历史中还原目标。补入正确记忆排除了该条记忆未被召回的情况,使比较更聚焦于信息已经提供后能否被使用,但差值仍包含理解与规划等因素。

core · described · diagnose · 对应问题 P1 §3.1–3.4

D2 · 保留完整交互轨迹,同时用分层用户画像图单独组织偏好事实和行为顺序。

画像图使偏好及其顺序关系更容易查找,原始轨迹继续提供行动示例。它回应了压缩历史可能损失示范的问题,但引入了额外的信息处理与上下文开销。

core · described · mitigate · 对应问题 P2 §6.1–6.2、图8–9

E1 §3.1–3.4 原文描述

两阶段评测保持场景和目标一致,改变指令的信息充分程度。默认检索五条历史;若缺少任务所需的正确记忆,则替换候选以补入它。

该控制主要考察记忆已经提供后的利用能力,不能单凭两阶段差值完成所有失败环节的因果分解。

查看原文 ↗

E2 表1、§4.2 作者报告结果

GPT-4o 的成功率从获取阶段的95.0%降到单记忆利用阶段的85.1%,下降9.9个百分点。

这是作者报告的同模型、不同阶段比较;下降幅度不能外推为所有模型或真实机器人的表现。

查看原文 ↗

E3 §4.1、附录A.1 编辑核验判断

主实验采用理想化感知与动作技能。多记忆任务还需要组合目标并承担额外的协调负担。

这些条件限制真实机器人外推,也限制把全部性能差值归因于单个记忆组件。

查看原文 ↗

E4 §6.1–6.2、图8–9 原文描述

作者比较完整轨迹与简化记忆,再提出用户—知识—元素的分层画像图,以时序边保存行为顺序,同时保留原有轨迹。作者报告加入画像后,两类任务的表现均改善。

这些结果支持考察事实与轨迹分开组织的价值;没有严格等预算对照,不能把收益全部归因于图结构。

查看原文 ↗

E5 表1与§4.2正文 编辑核验判断

表1中的GPT-4o单记忆成功率下降9.9个百分点,约为原成功率的10.4%;两种口径均不超过20%。

因此正文对所有模型下降超过20%的概括不能直接沿用;应逐项保留模型、任务和计算口径。

查看原文 ↗

原始来源

论文

ACE:用稳定条目和局部更新抑制上下文坍缩

关注的问题

长任务中的上下文更新容易偏向简短总结,反复整体重写会使有价值的细节消失。

作者的方法

将经验保存为稳定ID条目,用局部delta及确定性合并更新playbook。

  • 记忆与上下文
  • 身份与权限
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

长任务中的上下文更新容易偏向简短总结,反复整体重写会使有价值的细节消失。 §2.2

还需处理的问题

局部经验也可能冗余或有害。 §3.1–3.2

02 文章用了什么方法

主要方法

将经验保存为稳定ID条目,用局部delta及确定性合并更新playbook。

回应的问题

长任务中的上下文更新容易偏向简短总结,反复整体重写会使有价值的细节消失。

原文依据 §3.1–3.2

配套设计

用helpful/harmful计数、反思和去重管理条目。

回应的问题

局部经验也可能冗余或有害。

原文依据 §3.1–3.2

03 证据支持到哪里

从原文能确认什么

已核对条目ID、helpful/harmful计数、非LLM合并及在线“先预测后更新”顺序;成本表衡量的是适配阶段,不等于所有请求的端到端节省。 §3.1–3.2原文依据

这些结论有什么条件

效果依赖Reflector质量;原文明说简短固定规则就能解决的任务未必需要长playbook。 原文依据

04 总结与启发

我们的理解与启发

将上下文当作可局部修订的条目库,按任务复杂度决定是否引入反思与整理角色。 §3.1–3.2原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 长任务中的上下文更新容易偏向简短总结,反复整体重写会使有价值的细节消失。

primary §2.2

P2 · 局部经验也可能冗余或有害。

secondary · ↳ P1 §3.1–3.2

D1 · 将经验保存为稳定ID条目,用局部delta及确定性合并更新playbook。

core · described · 对应问题 P1 §3.1–3.2

D2 · 用helpful/harmful计数、反思和去重管理条目。

supporting · described · 对应问题 P2 · 支撑 D1 §3.1–3.2

E1 §2.2 原文描述

长任务中的上下文更新容易偏向简短总结,反复整体重写会使有价值的细节消失。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §3.1–3.2 原文描述

将经验保存为稳定ID条目,用局部delta及确定性合并更新playbook。 用helpful/harmful计数、反思和去重管理条目。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §4.1、§4.7、Limitations and Challenges 编辑核验判断

已核对条目ID、helpful/harmful计数、非LLM合并及在线“先预测后更新”顺序;成本表衡量的是适配阶段,不等于所有请求的端到端节省。 效果依赖Reflector质量;原文明说简短固定规则就能解决的任务未必需要长playbook。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

JIT-Agent:按任务生成并准入四模块 harness

关注的问题

固定harness难以匹配搜索、规划与工作区任务的不同控制和记忆需求。

作者的方法

按任务生成四模块harness,经协议和执行检查后选择一个候选装入固定内核。

  • 文件与工件
  • 记忆与上下文
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

固定harness难以匹配搜索、规划与工作区任务的不同控制和记忆需求。 §1、§3.1

还需处理的问题

生成的harness可能不符合接口或不能运行。 §3.1–3.2、§4.2

02 文章用了什么方法

主要方法

按任务生成四模块harness,经协议和执行检查后选择一个候选装入固定内核。

回应的问题

固定harness难以匹配搜索、规划与工作区任务的不同控制和记忆需求。

原文依据 §3.1–3.2、§4.2

配套设计

在选定前分别检查语法、协议和可执行性。

回应的问题

生成的harness可能不符合接口或不能运行。

原文依据 §3.1–3.2、§4.2

03 证据支持到哪里

从原文能确认什么

已核对四模块固定协议、生成后选择单一harness执行及streaming archive;不同模型与任务存在质量换成本的取舍,不是全面胜过固定harness。 §3.1–3.2、§4.2§5.1、§5.4–5.5

这些结论有什么条件

生成器经过训练且测试时冻结;跨模型结果使用50或100题子集,接口合规与执行成功也不等于安全保证。 §5.1、§5.4–5.5

04 总结与启发

我们的理解与启发

把可变策略放入显式接口,在生成产物与共享执行内核之间保持边界。 §3.1–3.2、§4.2§5.1、§5.4–5.5

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 固定harness难以匹配搜索、规划与工作区任务的不同控制和记忆需求。

primary §1、§3.1

P2 · 生成的harness可能不符合接口或不能运行。

secondary · ↳ P1 §3.1–3.2、§4.2

D1 · 按任务生成四模块harness,经协议和执行检查后选择一个候选装入固定内核。

core · described · 对应问题 P1 §3.1–3.2、§4.2

D2 · 在选定前分别检查语法、协议和可执行性。

supporting · described · 对应问题 P2 · 支撑 D1 §3.1–3.2、§4.2

E1 §1、§3.1 原文描述

固定harness难以匹配搜索、规划与工作区任务的不同控制和记忆需求。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §3.1–3.2、§4.2 原文描述

按任务生成四模块harness,经协议和执行检查后选择一个候选装入固定内核。 在选定前分别检查语法、协议和可执行性。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §5.1、§5.4–5.5 编辑核验判断

已核对四模块固定协议、生成后选择单一harness执行及streaming archive;不同模型与任务存在质量换成本的取舍,不是全面胜过固定harness。 生成器经过训练且测试时冻结;跨模型结果使用50或100题子集,接口合规与执行成功也不等于安全保证。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

BEAM / LIGHT:连续叙事中的更新、冲突与顺序探针

关注的问题

现有长对话测评缺少连续叙事和多类记忆能力;BEAM用人物、关系与时间线构造对话及可追溯问题。

作者的方法

构造连续人物与事件历史,用来源绑定的问题和原子评分测量长期记忆能力。

  • 记忆与上下文
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

现有长对话测评缺少连续叙事和多类记忆能力;BEAM用人物、关系与时间线构造对话及可追溯问题。 §2.2–2.4

02 文章用了什么方法

主要方法

构造连续人物与事件历史,用来源绑定的问题和原子评分测量长期记忆能力。

回应的问题

现有长对话测评缺少连续叙事和多类记忆能力;BEAM用人物、关系与时间线构造对话及可追溯问题。

原文依据 §3.1–3.2

03 证据支持到哪里

从原文能确认什么

已核对人工筛题、nugget评分和事件排序的Kendall tau-b;LIGHT并非逐能力都领先,working memory在100K–1M部分设置中没有正收益。 §3.1–3.2§4.1–4.2、表1、图3

这些结论有什么条件

数据是合成对话;10M场景的长上下文基线仅保留能装入窗口的近期历史,不能视为完整10M直接输入的同预算比较。 §4.1–4.2、表1、图3

04 总结与启发

我们的理解与启发

借鉴来源可定位的更新、冲突与顺序问题,并根据任务需要组合检索、近期缓冲和scratchpad。 §3.1–3.2§4.1–4.2、表1、图3

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 现有长对话测评缺少连续叙事和多类记忆能力;BEAM用人物、关系与时间线构造对话及可追溯问题。

primary §2.2–2.4

D1 · 构造连续人物与事件历史,用来源绑定的问题和原子评分测量长期记忆能力。

core · described · 对应问题 P1 §3.1–3.2

E1 §2.2–2.4 原文描述

现有长对话测评缺少连续叙事和多类记忆能力;BEAM用人物、关系与时间线构造对话及可追溯问题。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §3.1–3.2 原文描述

构造连续人物与事件历史,用来源绑定的问题和原子评分测量长期记忆能力。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §4.1–4.2、表1、图3 编辑核验判断

已核对人工筛题、nugget评分和事件排序的Kendall tau-b;LIGHT并非逐能力都领先,working memory在100K–1M部分设置中没有正收益。 数据是合成对话;10M场景的长上下文基线仅保留能装入窗口的近期历史,不能视为完整10M直接输入的同预算比较。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

MemGAS:From Single to Multi-Granularity: Toward Long-Term Memory Association and Selection of Conversational Agents

关注的问题

长期对话记忆包含会话、轮次、摘要与关键词,固定粒度难兼顾细节和检索噪声。

作者的方法

以逆熵软权重组合记忆粒度,在GMM关联图上经PPR扩展并过滤结果。

  • 记忆与上下文
  • 文件与工件
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

长期对话记忆包含会话、轮次、摘要与关键词,固定粒度难兼顾细节和检索噪声。 §2.1

02 文章用了什么方法

主要方法

以逆熵软权重组合记忆粒度,在GMM关联图上经PPR扩展并过滤结果。

回应的问题

长期对话记忆包含会话、轮次、摘要与关键词,固定粒度难兼顾细节和检索噪声。

原文依据 §2.2–2.4

03 证据支持到哪里

从原文能确认什么

已核对逆熵软权重、GMM关联、PPR和LLM过滤;表1中LoCoMo的GPT-4o-J并非最优,不能概括成所有指标都胜出。 §2.2–2.4表1、表3、§3.1

这些结论有什么条件

部分大型基线因运行成本缺席LongMemEval-m;相同top-k不等于相同token成本,论文也未在所有指标上领先。 表1、表3、§3.1

04 总结与启发

我们的理解与启发

把粒度选择与关系传播分开理解,依据问题类型选择上下文,而非把更细粒度一律当作更好。 §2.2–2.4表1、表3、§3.1

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 长期对话记忆包含会话、轮次、摘要与关键词,固定粒度难兼顾细节和检索噪声。

primary §2.1

D1 · 以逆熵软权重组合记忆粒度,在GMM关联图上经PPR扩展并过滤结果。

core · described · 对应问题 P1 §2.2–2.4

E1 §2.1 原文描述

长期对话记忆包含会话、轮次、摘要与关键词,固定粒度难兼顾细节和检索噪声。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §2.2–2.4 原文描述

以逆熵软权重组合记忆粒度,在GMM关联图上经PPR扩展并过滤结果。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 表1、表3、§3.1 编辑核验判断

已核对逆熵软权重、GMM关联、PPR和LLM过滤;表1中LoCoMo的GPT-4o-J并非最优,不能概括成所有指标都胜出。 部分大型基线因运行成本缺席LongMemEval-m;相同top-k不等于相同token成本,论文也未在所有指标上领先。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Cordis:A Programming Paradigm for Spatiotemporal Composability

关注的问题

动态插件系统既要清理撤载副作用,也要在依赖提供者变化时调整消费者生命周期。

作者的方法

把提供能力、依赖关系和清理函数纳入生命周期,撤载时先停供再等待依赖者退出。

  • 工具与协议
  • 文件与工件
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

动态插件系统既要清理撤载副作用,也要在依赖提供者变化时调整消费者生命周期。 §1.1–1.2

还需处理的问题

目标在生命周期转换途中变化,会使清理和重建交错。 §5.1.2–5.1.3、算法4–5

02 文章用了什么方法

主要方法

把提供能力、依赖关系和清理函数纳入生命周期,撤载时先停供再等待依赖者退出。

回应的问题

动态插件系统既要清理撤载副作用,也要在依赖提供者变化时调整消费者生命周期。

原文依据 §5.1.2–5.1.3、算法4–5

配套设计

先完成当前LOADING或UNLOADING转换,再响应新的目标状态。

回应的问题

目标在生命周期转换途中变化,会使清理和重建交错。

原文依据 §5.1.2–5.1.3、算法4–5

03 证据支持到哪里

从原文能确认什么

已核对先停止提供、等待依赖者退出、再清理的顺序,以及惯性状态转换;Cordis并不保证撤销已经发送到外界的数据。 §5.1.2–5.1.3、算法4–5§5.3、§6.1、§6.3

这些结论有什么条件

形式保证限于受context管理且可逆的边界;Koishi案例是单生态观察证据,不提供架构间定量因果对照;不可信代码仍需外部沙箱。 §5.3、§6.1、§6.3

04 总结与启发

我们的理解与启发

将能力声明、依赖有效性和撤载清理放在统一生命周期中,明确外部不可逆操作的边界。 §5.1.2–5.1.3、算法4–5§5.3、§6.1、§6.3

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 动态插件系统既要清理撤载副作用,也要在依赖提供者变化时调整消费者生命周期。

primary §1.1–1.2

P2 · 目标在生命周期转换途中变化,会使清理和重建交错。

secondary · ↳ P1 §5.1.2–5.1.3、算法4–5

D1 · 把提供能力、依赖关系和清理函数纳入生命周期,撤载时先停供再等待依赖者退出。

core · described · 对应问题 P1 §5.1.2–5.1.3、算法4–5

D2 · 先完成当前LOADING或UNLOADING转换,再响应新的目标状态。

supporting · described · 对应问题 P2 · 支撑 D1 §5.1.2–5.1.3、算法4–5

E1 §1.1–1.2 原文描述

动态插件系统既要清理撤载副作用,也要在依赖提供者变化时调整消费者生命周期。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §5.1.2–5.1.3、算法4–5 原文描述

把提供能力、依赖关系和清理函数纳入生命周期,撤载时先停供再等待依赖者退出。 先完成当前LOADING或UNLOADING转换,再响应新的目标状态。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §5.3、§6.1、§6.3 编辑核验判断

已核对先停止提供、等待依赖者退出、再清理的顺序,以及惯性状态转换;Cordis并不保证撤销已经发送到外界的数据。 形式保证限于受context管理且可逆的边界;Koishi案例是单生态观察证据,不提供架构间定量因果对照;不可信代码仍需外部沙箱。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

How Memory Management Impacts LLM Agents: An Empirical Study of Experience-Following Behavior

关注的问题

Agent把自身执行轨迹加入记忆,后续任务又会模仿相似经验,错误和不适用策略因此可能持续传播。

作者的方法

按检索次数与后续任务效用管理记忆保留和删除,比较不同管理策略。

  • 记忆与上下文
  • 状态与恢复
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

Agent把自身执行轨迹加入记忆,后续任务又会模仿相似经验,错误和不适用策略因此可能持续传播。 §3.1–3.3

02 文章用了什么方法

主要方法

按检索次数与后续任务效用管理记忆保留和删除,比较不同管理策略。

回应的问题

Agent把自身执行轨迹加入记忆,后续任务又会模仿相似经验,错误和不适用策略因此可能持续传播。

原文依据 §3.4、§4.1–4.3

03 证据支持到哪里

从原文能确认什么

已核对真值替换对照、按检索次数和后续任务效用删除的规则;原始执行看似正确,不代表它对未来查询有帮助。 §3.4、§4.1–4.3§5、Limitations

这些结论有什么条件

研究主要覆盖添加与删除,没有覆盖合并、摘要和结构重写;作者明确将发现限定为经验研究而非形式保证。 §5、Limitations

04 总结与启发

我们的理解与启发

记忆价值应结合后续使用效果理解,并将记录的正确性与可迁移性分开判断。 §3.4、§4.1–4.3§5、Limitations

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · Agent把自身执行轨迹加入记忆,后续任务又会模仿相似经验,错误和不适用策略因此可能持续传播。

primary §3.1–3.3

D1 · 按检索次数与后续任务效用管理记忆保留和删除,比较不同管理策略。

core · described · 对应问题 P1 §3.4、§4.1–4.3

E1 §3.1–3.3 原文描述

Agent把自身执行轨迹加入记忆,后续任务又会模仿相似经验,错误和不适用策略因此可能持续传播。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §3.4、§4.1–4.3 原文描述

按检索次数与后续任务效用管理记忆保留和删除,比较不同管理策略。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §5、Limitations 编辑核验判断

已核对真值替换对照、按检索次数和后续任务效用删除的规则;原始执行看似正确,不代表它对未来查询有帮助。 研究主要覆盖添加与删除,没有覆盖合并、摘要和结构重写;作者明确将发现限定为经验研究而非形式保证。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Faster, cheaper support investigations with precomputed context

关注的问题

支持调查反复跨工单、对话和工程资料收集同一组证据,索引路由优化仍未消除重复综合成本。

作者的方法

预计算带来源和证据水位的case知识,将路由profile与案例事实分离。

  • 记忆与上下文
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

支持调查反复跨工单、对话和工程资料收集同一组证据,索引路由优化仍未消除重复综合成本。 原文依据

还需处理的问题

缓存事实可能落后于实时系统。 原文依据

02 文章用了什么方法

主要方法

预计算带来源和证据水位的case知识,将路由profile与案例事实分离。

回应的问题

支持调查反复跨工单、对话和工程资料收集同一组证据,索引路由优化仍未消除重复综合成本。

原文依据 原文依据

配套设计

显式保存证据水位和假设状态,查询实时状态时以权威系统为准。

回应的问题

缓存事实可能落后于实时系统。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对case KI与index profile的分工、水位和实时状态优先规则;效率数字来自20个问题、每题3次试验,事实性由独立LLM judge评分。 原文依据What we observed

这些结论有什么条件

这是小样本方向性结果;“未观察到显著下降”不等于证明事实性等价,58%输入token下降仅对应其中的案例调查流程。 What we observed

04 总结与启发

我们的理解与启发

按稳定案例标识预计算带来源和假设状态的证据包,并保留当前状态的权威查询入口。 原文依据What we observed

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 支持调查反复跨工单、对话和工程资料收集同一组证据,索引路由优化仍未消除重复综合成本。

primary 原文依据

P2 · 缓存事实可能落后于实时系统。

secondary · ↳ P1 原文依据

D1 · 预计算带来源和证据水位的case知识,将路由profile与案例事实分离。

core · described · 对应问题 P1 原文依据

D2 · 显式保存证据水位和假设状态,查询实时状态时以权威系统为准。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 文章导言、Starting with index profiles 原文描述

支持调查反复跨工单、对话和工程资料收集同一组证据,索引路由优化仍未消除重复综合成本。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Changing the unit of context、The retrieval skill is part of the system 原文描述

预计算带来源和证据水位的case知识,将路由profile与案例事实分离。 显式保存证据水位和假设状态,查询实时状态时以权威系统为准。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 What we observed 编辑核验判断

已核对case KI与index profile的分工、水位和实时状态优先规则;效率数字来自20个问题、每题3次试验,事实性由独立LLM judge评分。 这是小样本方向性结果;“未观察到显著下降”不等于证明事实性等价,58%输入token下降仅对应其中的案例调查流程。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

When Personalization Legitimizes Risks: Uncovering Safety Vulnerabilities in Personalized Dialogue Agents

关注的问题

良性个人历史可能改变对危险请求的意图判断,个性化记忆本身也会带来安全偏移。

作者的方法

固定风险问题比较无记忆和良性个人历史,另分析detect-and-reflect防护的效用代价。

  • 安全与隔离
  • 记忆与上下文
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

良性个人历史可能改变对危险请求的意图判断,个性化记忆本身也会带来安全偏移。 §1、§3.1–3.4

02 文章用了什么方法

主要方法

固定风险问题比较无记忆和良性个人历史,另分析detect-and-reflect防护的效用代价。

回应的问题

良性个人历史可能改变对危险请求的意图判断,个性化记忆本身也会带来安全偏移。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对stateless对照和detect-and-reflect流程;表1的15.8%–243.7%是ASR相对增幅,表2显示A-Mem的个性化效用有明显损失。 原文依据表1–2、Limitations

这些结论有什么条件

研究是文本、孤立单轮安全问题,不含工具执行;抑制风险与维持个性化之间的取舍因框架而异。 表1–2、Limitations

04 总结与启发

我们的理解与启发

把个人背景作为解释线索而非行为授权,阅读安全结论时同时看正常任务效用。 原文依据表1–2、Limitations

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 良性个人历史可能改变对危险请求的意图判断,个性化记忆本身也会带来安全偏移。

primary §1、§3.1–3.4

D1 · 固定风险问题比较无记忆和良性个人历史,另分析detect-and-reflect防护的效用代价。

core · described · 对应问题 P1 原文依据

E1 §1、§3.1–3.4 原文描述

良性个人历史可能改变对危险请求的意图判断,个性化记忆本身也会带来安全偏移。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §4 A Simple Intervention for Intent Legitimation 原文描述

固定风险问题比较无记忆和良性个人历史,另分析detect-and-reflect防护的效用代价。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 表1–2、Limitations 编辑核验判断

已核对stateless对照和detect-and-reflect流程;表1的15.8%–243.7%是ASR相对增幅,表2显示A-Mem的个性化效用有明显损失。 研究是文本、孤立单轮安全问题,不含工具执行;抑制风险与维持个性化之间的取舍因框架而异。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Controllable Memory Usage: Balancing Anchoring and Innovation in Long-Term Human-Agent Interaction

关注的问题

用户有时要求沿用历史,有时要求跳出旧思路;相关记忆被召回后仍可能造成过度依赖。

作者的方法

以MD-Score度量目标记忆依赖,结合偏好SFT与GRPO训练可控依赖行为。

  • 记忆与上下文
  • 文件与工件
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

用户有时要求沿用历史,有时要求跳出旧思路;相关记忆被召回后仍可能造成过度依赖。 §3.1–3.3

02 文章用了什么方法

主要方法

以MD-Score度量目标记忆依赖,结合偏好SFT与GRPO训练可控依赖行为。

回应的问题

用户有时要求沿用历史,有时要求跳出旧思路;相关记忆被召回后仍可能造成过度依赖。

原文依据 §4.2–4.3

03 证据支持到哪里

从原文能确认什么

已核对1–5级MD-Score、目标偏差、偏好对齐SFT和GRPO;SteeM包含参数训练,不能当作只改prompt即可取得相同效果。 §4.2–4.3§5.3、Limitations、附录G

这些结论有什么条件

数据仅覆盖Research和Tutoring,离散等级不能表达所有真实偏好;与masking的比较包含不同训练与推理成本。 §5.3、Limitations、附录G

04 总结与启发

我们的理解与启发

将用户要求的记忆依赖程度与检索相关性分别表达,避免把“想换个思路”误解成缺少更多历史。 §4.2–4.3§5.3、Limitations、附录G

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 用户有时要求沿用历史,有时要求跳出旧思路;相关记忆被召回后仍可能造成过度依赖。

primary §3.1–3.3

D1 · 以MD-Score度量目标记忆依赖,结合偏好SFT与GRPO训练可控依赖行为。

core · described · 对应问题 P1 §4.2–4.3

E1 §3.1–3.3 原文描述

用户有时要求沿用历史,有时要求跳出旧思路;相关记忆被召回后仍可能造成过度依赖。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §4.2–4.3 原文描述

以MD-Score度量目标记忆依赖,结合偏好SFT与GRPO训练可控依赖行为。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §5.3、Limitations、附录G 编辑核验判断

已核对1–5级MD-Score、目标偏差、偏好对齐SFT和GRPO;SteeM包含参数训练,不能当作只改prompt即可取得相同效果。 数据仅覆盖Research和Tutoring,离散等级不能表达所有真实偏好;与masking的比较包含不同训练与推理成本。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Shopify:让修复完成跟随当前事实,而不是跟随 Agent 的上一份计划

关注的问题

漏洞补丁在等待评审时可能失鲜,PR通过CI也不代表默认分支中的漏洞已经消失。

作者的方法

将claim账本与当前仓库SHA、PR和默认分支结果持续对账后判断关闭。

  • 安全与隔离
  • 观测与评测
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

漏洞补丁在等待评审时可能失鲜,PR通过CI也不代表默认分支中的漏洞已经消失。 原文依据

02 文章用了什么方法

主要方法

将claim账本与当前仓库SHA、PR和默认分支结果持续对账后判断关闭。

回应的问题

漏洞补丁在等待评审时可能失鲜,PR通过CI也不代表默认分支中的漏洞已经消失。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对ledger/live repo对账、当前SHA证据和合并后关闭条件;原文明确承认曾只检查最旧一条claim,prompt中的完整枚举不是执行保证。 原文依据原文依据

这些结论有什么条件

70%积压下降是11天生产观察且包含已过时/别处已修复项;并非70%都由新补丁修好,也不是控制实验的效果归因。 原文依据

04 总结与启发

我们的理解与启发

将完成条件绑定到当前源码与业务记录,并让交接保留证据、责任主体和未决问题。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 漏洞补丁在等待评审时可能失鲜,PR通过CI也不代表默认分支中的漏洞已经消失。

primary 原文依据

D1 · 将claim账本与当前仓库SHA、PR和默认分支结果持续对账后判断关闭。

core · described · 对应问题 P1 原文依据

E1 The pipeline starts after the patch appears 原文描述

漏洞补丁在等待评审时可能失鲜,PR通过CI也不代表默认分支中的漏洞已经消失。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Validate the live state、Repair and iterate on the current head、Verify closure 原文描述

将claim账本与当前仓库SHA、PR和默认分支结果持续对账后判断关闭。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 A workflow prompt isn't a control plane 编辑核验判断

已核对ledger/live repo对账、当前SHA证据和合并后关闭条件;原文明确承认曾只检查最旧一条claim,prompt中的完整枚举不是执行保证。 70%积压下降是11天生产观察且包含已过时/别处已修复项;并非70%都由新补丁修好,也不是控制实验的效果归因。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

MetaMask:把 Agent 权限编译成资源端可撤销、不可放大的委托链

关注的问题

自治客户端需要在用户授予的范围内支出,而全权私钥或逐笔人审都无法同时满足其目标。

作者的方法

由资源侧验证链上委托caveat,子委托只能收窄并检查到期与撤销。

  • 身份与权限
  • 工具与协议
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

自治客户端需要在用户授予的范围内支出,而全权私钥或逐笔人审都无法同时满足其目标。 原文依据

还需处理的问题

委托继续转交可能扩大原先权限。 原文依据

02 文章用了什么方法

主要方法

由资源侧验证链上委托caveat,子委托只能收窄并检查到期与撤销。

回应的问题

自治客户端需要在用户授予的范围内支出,而全权私钥或逐笔人审都无法同时满足其目标。

原文依据 原文依据

配套设计

完整验证委托链,要求子委托范围不大于上游并支持到期或撤销。

回应的问题

委托继续转交可能扩大原先权限。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对链上caveat、到期/撤销及较窄子委托;拒绝后不退回自行签名的说明特指Hermes客户端,不能概括为所有客户端路径。 原文依据原文依据

这些结论有什么条件

案例由供应商与集成方报告;交易额属于launchpad业务结果,并不证明委托机制的安全收益。 原文依据

04 总结与启发

我们的理解与启发

将授权边界落在被调用资源能执行的规则上,同时区分无匹配授权与明确被拒绝两种后续行为。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 自治客户端需要在用户授予的范围内支出,而全权私钥或逐笔人审都无法同时满足其目标。

primary 原文依据

P2 · 委托继续转交可能扩大原先权限。

secondary · ↳ P1 原文依据

D1 · 由资源侧验证链上委托caveat,子委托只能收窄并检查到期与撤销。

core · described · 对应问题 P1 原文依据

D2 · 完整验证委托链,要求子委托范围不大于上游并支持到期或撤销。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Income without spending controls is still a liability 原文描述

自治客户端需要在用户授予的范围内支出,而全权私钥或逐笔人审都无法同时满足其目标。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 The architecture: caveats enforced by the chain, not the agent 原文描述

由资源侧验证链上委托caveat,子委托只能收窄并检查到期与撤销。 完整验证委托链,要求子委托范围不大于上游并支持到期或撤销。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Revocation that fails closed、Impact so far 编辑核验判断

已核对链上caveat、到期/撤销及较窄子委托;拒绝后不退回自行签名的说明特指Hermes客户端,不能概括为所有客户端路径。 案例由供应商与集成方报告;交易额属于launchpad业务结果,并不证明委托机制的安全收益。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Datadog:Agent 安全必须从组件清单升级为全会话序列检测

关注的问题

只看最终API或模型输入输出,会漏掉预处理命令、工具数据和跨步骤攻击路径。

作者的方法

把输入、动态上下文、工具及出站行为关联成完整trace,再做序列检测与身份归因。

  • 工具与协议
  • 记忆与上下文
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

只看最终API或模型输入输出,会漏掉预处理命令、工具数据和跨步骤攻击路径。 原文依据

02 文章用了什么方法

主要方法

把输入、动态上下文、工具及出站行为关联成完整trace,再做序列检测与身份归因。

回应的问题

只看最终API或模型输入输出,会漏掉预处理命令、工具数据和跨步骤攻击路径。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对AI-BOM、三类身份归因和序列检测;原文明说“敏感输出与可疑prompt同时出现”只是调查线索,还要看到响应暴露或未授权出站才能判断外泄。 原文依据原文依据

这些结论有什么条件

异常成本、token增长或可疑序列不能单独当作安全事件;工具侧与接收服务侧仍分别承担执行约束。 原文依据

04 总结与启发

我们的理解与启发

围绕同一会话保留从输入到副作用的证据链,并把可疑路径与已发生后果分开呈现。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 只看最终API或模型输入输出,会漏掉预处理命令、工具数据和跨步骤攻击路径。

primary 原文依据

D1 · 把输入、动态上下文、工具及出站行为关联成完整trace,再做序列检测与身份归因。

core · described · 对应问题 P1 原文依据

E1 What telemetry data should you collect for AI agent security? 原文描述

只看最终API或模型输入输出,会漏掉预处理命令、工具数据和跨步骤攻击路径。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Start with an inventory that includes more than models、Monitor AI agent prompts and tool execution together 原文描述

把输入、动态上下文、工具及出站行为关联成完整trace,再做序列检测与身份归因。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Keep the human and agent identities distinct、Build detections around behavior instead of isolated events 编辑核验判断

已核对AI-BOM、三类身份归因和序列检测;原文明说“敏感输出与可疑prompt同时出现”只是调查线索,还要看到响应暴露或未授权出站才能判断外泄。 异常成本、token增长或可疑序列不能单独当作安全事件;工具侧与接收服务侧仍分别承担执行约束。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Datadog:为 Agent 提供机器可判定的服务目录与完整 dispatch contract

关注的问题

面向人的Golden Path缺少Agent可机器读取的能力契约与确定性流程边界。

作者的方法

用类型化能力合同和权威目录连接工具发现、显式派发及同任务身份的恢复。

  • 状态与恢复
  • 身份与权限
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

面向人的Golden Path缺少Agent可机器读取的能力契约与确定性流程边界。 原文依据

02 文章用了什么方法

主要方法

用类型化能力合同和权威目录连接工具发现、显式派发及同任务身份的恢复。

回应的问题

面向人的Golden Path缺少Agent可机器读取的能力契约与确定性流程边界。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对有类型的能力接口、权威目录、显式dispatch链及恢复时保留task identity;文中的约40%节省属于特定查询工具场景,不是整套架构收益。 原文依据原文依据

这些结论有什么条件

文章主要提供设计建议和内部案例,不能将每一项推荐都理解成已经交付的通用平台保证。 原文依据

04 总结与启发

我们的理解与启发

用可读契约描述能力,用目录确定权威元数据,让派发显式绑定任务、权限、环境与结果。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 面向人的Golden Path缺少Agent可机器读取的能力契约与确定性流程边界。

primary 原文依据

D1 · 用类型化能力合同和权威目录连接工具发现、显式派发及同任务身份的恢复。

core · described · 对应问题 P1 原文依据

E1 Match AI agent execution patterns to workload requirements 原文描述

面向人的Golden Path缺少Agent可机器读取的能力契约与确定性流程边界。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Expose capabilities through structured interfaces、Make dispatch an explicit step in agent-facing Golden Paths 原文描述

用类型化能力合同和权威目录连接工具发现、显式派发及同任务身份的恢复。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Keep the service catalog authoritative、Build checkpoints and retry budgets into AI agent workflows 编辑核验判断

已核对有类型的能力接口、权威目录、显式dispatch链及恢复时保留task identity;文中的约40%节省属于特定查询工具场景,不是整套架构收益。 文章主要提供设计建议和内部案例,不能将每一项推荐都理解成已经交付的通用平台保证。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

NVIDIA:让长期记忆提供证据与优先级,但不能自行变成权限

关注的问题

企业记忆需要连接不断变化的人物、项目与义务,单纯保留对话或检索片段难以维持一致判断。

作者的方法

以Markdown self model组织用户事实,以SQLite义务账本和intent gate约束后续判断。

  • 记忆与上下文
  • 身份与权限
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

企业记忆需要连接不断变化的人物、项目与义务,单纯保留对话或检索片段难以维持一致判断。 原文依据

02 文章用了什么方法

主要方法

以Markdown self model组织用户事实,以SQLite义务账本和intent gate约束后续判断。

回应的问题

企业记忆需要连接不断变化的人物、项目与义务,单纯保留对话或检索片段难以维持一致判断。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Markdown self model、SQLite义务账本和intent gate;表1的总体准确率提高,但忠实回答与单跳查询下降,不能说所有任务都改善。 原文依据原文依据

这些结论有什么条件

公开recipe不发送消息或修改源系统;变更事实一项只有5题,100%结果不能被外推为普遍可靠。 原文依据

04 总结与启发

我们的理解与启发

分开存储来源证据、派生知识和判断记录,让用户纠正可追踪;记忆内容不直接充当权限。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 企业记忆需要连接不断变化的人物、项目与义务,单纯保留对话或检索片段难以维持一致判断。

primary 原文依据

D1 · 以Markdown self model组织用户事实,以SQLite义务账本和intent gate约束后续判断。

core · described · 对应问题 P1 原文依据

E1 Maintain context across daily work 原文描述

企业记忆需要连接不断变化的人物、项目与义务,单纯保留对话或检索片段难以维持一致判断。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Separate evidence, knowledge, and action、Prioritize user intent over short-term urgency 原文描述

以Markdown self model组织用户事实,以SQLite义务账本和intent gate约束后续判断。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 表1、Get started building agent memory 编辑核验判断

已核对Markdown self model、SQLite义务账本和intent gate;表1的总体准确率提高,但忠实回答与单跳查询下降,不能说所有任务都改善。 公开recipe不发送消息或修改源系统;变更事实一项只有5题,100%结果不能被外推为普遍可靠。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Oracle:把模型读取与人工审批拆成不同的 MCP 调用域

关注的问题

供应链推荐需要跨不同Agent宿主呈现,同时让人工审批只授权眼前的确定调拨。

作者的方法

用仅widget可见的approvalId绑定actor与不可变推荐,由app-only工具提交数据库事务。

  • 工具与协议
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

供应链推荐需要跨不同Agent宿主呈现,同时让人工审批只授权眼前的确定调拨。 Key Takeaways

还需处理的问题

用户批准后库存可能已经变化。 原文依据

02 文章用了什么方法

主要方法

用仅widget可见的approvalId绑定actor与不可变推荐,由app-only工具提交数据库事务。

回应的问题

供应链推荐需要跨不同Agent宿主呈现,同时让人工审批只授权眼前的确定调拨。

原文依据 原文依据

配套设计

数据库加锁重算可行性,再在同一事务中写入转移和审计。

回应的问题

用户批准后库存可能已经变化。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对widget-only approvalId、app-only审批工具和数据库加锁重算;审批绑定actor及不可变推荐,浏览器不能替换产品和数量。 原文依据原文依据

这些结论有什么条件

这是参考实现;iframe隔离依赖宿主执行,不能替代服务器鉴权和数据库事务。 原文依据

04 总结与启发

我们的理解与启发

将读取、展示、审批和提交分别设边界,在提交时核对实时库存。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 供应链推荐需要跨不同Agent宿主呈现,同时让人工审批只授权眼前的确定调拨。

primary Key Takeaways

P2 · 用户批准后库存可能已经变化。

secondary · ↳ P1 原文依据

D1 · 用仅widget可见的approvalId绑定actor与不可变推荐,由app-only工具提交数据库事务。

core · described · 对应问题 P1 原文依据

D2 · 数据库加锁重算可行性,再在同一事务中写入转移和审计。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Key Takeaways 原文描述

供应链推荐需要跨不同Agent宿主呈现,同时让人工审批只授权眼前的确定调拨。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Add a Supply-Chain Dashboard with MCP Apps、Bind Human Approval to One Exact Transfer 原文描述

用仅widget可见的approvalId绑定actor与不可变推荐,由app-only工具提交数据库事务。 数据库加锁重算可行性,再在同一事务中写入转移和审计。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 What Does Sandboxed Iframe Mean 编辑核验判断

已核对widget-only approvalId、app-only审批工具和数据库加锁重算;审批绑定actor及不可变推荐,浏览器不能替换产品和数量。 这是参考实现;iframe隔离依赖宿主执行,不能替代服务器鉴权和数据库事务。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Temporal / Manetu:先区分恢复语义,再滚转长寿命 Agent

关注的问题

长寿命Agent的恢复、状态与执行身份需要跨进程保留,而人工继续和崩溃恢复携带的输入不同。

作者的方法

把Thread、Run和Checkpoint分别映射到Workflow、Activity与Update,区分人工输入和崩溃恢复。

  • 状态与恢复
  • 工具与协议
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

长寿命Agent的恢复、状态与执行身份需要跨进程保留,而人工继续和崩溃恢复携带的输入不同。 原文依据

还需处理的问题

历史滚转时外部进程可能仍在执行。 原文依据

02 文章用了什么方法

主要方法

把Thread、Run和Checkpoint分别映射到Workflow、Activity与Update,区分人工输入和崩溃恢复。

回应的问题

长寿命Agent的恢复、状态与执行身份需要跨进程保留,而人工继续和崩溃恢复携带的输入不同。

原文依据 原文依据

配套设计

Continue-as-New前处理未完成Activity并等待对应进程退出。

回应的问题

历史滚转时外部进程可能仍在执行。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Thread/Workflow、Run/Activity、Checkpoint/Update映射及滚转前等待进程退出;实现仅保留最新LangGraph checkpoint。 原文依据原文依据

这些结论有什么条件

该方案依赖特定运行时拦截及框架映射;透明恢复不自动证明任意外部副作用具备精确一次语义。 原文依据

04 总结与启发

我们的理解与启发

把业务会话身份与工作进程解耦,明确每类恢复是否应携带新输入。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 长寿命Agent的恢复、状态与执行身份需要跨进程保留,而人工继续和崩溃恢复携带的输入不同。

primary 原文依据

P2 · 历史滚转时外部进程可能仍在执行。

secondary · ↳ P1 原文依据

D1 · 把Thread、Run和Checkpoint分别映射到Workflow、Activity与Update,区分人工输入和崩溃恢复。

core · described · 对应问题 P1 原文依据

D2 · Continue-as-New前处理未完成Activity并等待对应进程退出。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Where durability lives、What durable means here 原文描述

长寿命Agent的恢复、状态与执行身份需要跨进程保留,而人工继续和崩溃恢复携带的输入不同。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Two kinds of resume、Challenges with Continue as New 原文描述

把Thread、Run和Checkpoint分别映射到Workflow、Activity与Update,区分人工输入和崩溃恢复。 Continue-as-New前处理未完成Activity并等待对应进程退出。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 A thread lives for months、Completing the Picture 编辑核验判断

已核对Thread/Workflow、Run/Activity、Checkpoint/Update映射及滚转前等待进程退出;实现仅保留最新LangGraph checkpoint。 该方案依赖特定运行时拦截及框架映射;透明恢复不自动证明任意外部副作用具备精确一次语义。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Cloudflare:让 Agent 决定图表,让已抓数据决定数值

关注的问题

多轮网络调查既需要保留查询上下文,也需要让图表数值能追溯到真实API结果。

作者的方法

每会话用Durable Object及SQLite保留状态,Code Mode按需查API,图表引用已获取数据。

  • 工具与协议
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

多轮网络调查既需要保留查询上下文,也需要让图表数值能追溯到真实API结果。 How we built it

还需处理的问题

模型重写数值会使图表偏离实际返回结果。 From Markdown to real charts

02 文章用了什么方法

主要方法

每会话用Durable Object及SQLite保留状态,Code Mode按需查API,图表引用已获取数据。

回应的问题

多轮网络调查既需要保留查询上下文,也需要让图表数值能追溯到真实API结果。

原文依据 From Markdown to real charts

配套设计

图表规格通过dataFrom引用相同API路径已有的数据。

回应的问题

模型重写数值会使图表偏离实际返回结果。

原文依据 From Markdown to real charts

03 证据支持到哪里

从原文能确认什么

已核对每会话Durable Object和SQLite、Code Mode动态发现,以及chart spec用dataFrom关联同路径抓取结果。 From Markdown to real chartsA few small touches、beta说明

这些结论有什么条件

数据绑定减少数值重造,不保证模型选对查询范围、指标或图表;产品仍为beta。 A few small touches、beta说明

04 总结与启发

我们的理解与启发

让模型选择呈现方式,由已取得的结构化数据填充数值,并保留会话恢复状态。 From Markdown to real chartsA few small touches、beta说明

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 多轮网络调查既需要保留查询上下文,也需要让图表数值能追溯到真实API结果。

primary How we built it

P2 · 模型重写数值会使图表偏离实际返回结果。

secondary · ↳ P1 From Markdown to real charts

D1 · 每会话用Durable Object及SQLite保留状态,Code Mode按需查API,图表引用已获取数据。

core · described · 对应问题 P1 From Markdown to real charts

D2 · 图表规格通过dataFrom引用相同API路径已有的数据。

supporting · described · 对应问题 P2 · 支撑 D1 From Markdown to real charts

E1 How we built it 原文描述

多轮网络调查既需要保留查询上下文,也需要让图表数值能追溯到真实API结果。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 From Markdown to real charts 原文描述

每会话用Durable Object及SQLite保留状态,Code Mode按需查API,图表引用已获取数据。 图表规格通过dataFrom引用相同API路径已有的数据。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 A few small touches、beta说明 编辑核验判断

已核对每会话Durable Object和SQLite、Code Mode动态发现,以及chart spec用dataFrom关联同路径抓取结果。 数据绑定减少数值重造,不保证模型选对查询范围、指标或图表;产品仍为beta。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Your agent's guardrails have a bypass

关注的问题

不同Agent框架的治理接口无法保证在相同执行位置做出相同处理。

作者的方法

定义allow、deny、transform协议及宿主执行义务,并对错误采用失败关闭。

  • 工具与协议
  • 状态与恢复
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

不同Agent框架的治理接口无法保证在相同执行位置做出相同处理。 The bypass、AGENT-HOOKS 0.1

还需处理的问题

旧批准可能被用到已经变化的调用上。 八个hook、三种verdict、approval绑定

02 文章用了什么方法

主要方法

定义allow、deny、transform协议及宿主执行义务,并对错误采用失败关闭。

回应的问题

不同Agent框架的治理接口无法保证在相同执行位置做出相同处理。

原文依据 八个hook、三种verdict、approval绑定

配套设计

将审批绑定调用上下文指纹,由宿主核对后执行。

回应的问题

旧批准可能被用到已经变化的调用上。

原文依据 八个hook、三种verdict、approval绑定

03 证据支持到哪里

从原文能确认什么

已核对allow/deny/transform、失败关闭和审批上下文指纹;47项符合性场景不是所有示例框架都获得认证。 八个hook、三种verdict、approval绑定原文依据

这些结论有什么条件

契约以可信宿主合作执行为前提,不是对恶意宿主的安全边界;流式处理还存在缓冲与暴露量取舍。 原文依据

04 总结与启发

我们的理解与启发

将拦截点和决策责任显式化,同时在运行环境处理宿主可绕过的风险。 八个hook、三种verdict、approval绑定原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 不同Agent框架的治理接口无法保证在相同执行位置做出相同处理。

primary The bypass、AGENT-HOOKS 0.1

P2 · 旧批准可能被用到已经变化的调用上。

secondary · ↳ P1 八个hook、三种verdict、approval绑定

D1 · 定义allow、deny、transform协议及宿主执行义务,并对错误采用失败关闭。

core · described · 对应问题 P1 八个hook、三种verdict、approval绑定

D2 · 将审批绑定调用上下文指纹,由宿主核对后执行。

supporting · described · 对应问题 P2 · 支撑 D1 八个hook、三种verdict、approval绑定

E1 The bypass、AGENT-HOOKS 0.1 原文描述

不同Agent框架的治理接口无法保证在相同执行位置做出相同处理。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 八个hook、三种verdict、approval绑定 原文描述

定义allow、deny、transform协议及宿主执行义务,并对错误采用失败关闭。 将审批绑定调用上下文指纹,由宿主核对后执行。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Conformance、FAQ security boundary 编辑核验判断

已核对allow/deny/transform、失败关闭和审批上下文指纹;47项符合性场景不是所有示例框架都获得认证。 契约以可信宿主合作执行为前提,不是对恶意宿主的安全边界;流式处理还存在缓冲与暴露量取舍。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Stop restricting the agent. Start restricting its environment.

关注的问题

执行型运维Agent可能利用环境能力绕过自身prompt中的操作限制。

作者的方法

以单Agent隔离环境及调用代理隔开代码和原始凭据,生产写操作经过人工审查。

  • 身份与权限
  • 工具与协议
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

执行型运维Agent可能利用环境能力绕过自身prompt中的操作限制。 失败案例

02 文章用了什么方法

主要方法

以单Agent隔离环境及调用代理隔开代码和原始凭据,生产写操作经过人工审查。

回应的问题

执行型运维Agent可能利用环境能力绕过自身prompt中的操作限制。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对单Agent隔离和调用代理注入凭证;当前生产写操作仍需人审,输出secret scrubbing是内部pilot,风险分级自动放行尚在建设。 原文依据Where it breaks、当前与规划能力

这些结论有什么条件

原文承认替代执行路径和MCP契约扩大仍可能绕过限制;不能将规划能力写成已交付保证。 Where it breaks、当前与规划能力

04 总结与启发

我们的理解与启发

把可信控制和不可信工作负载分开,按实际操作与目标限制能力。 原文依据Where it breaks、当前与规划能力

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 执行型运维Agent可能利用环境能力绕过自身prompt中的操作限制。

primary 失败案例

D1 · 以单Agent隔离环境及调用代理隔开代码和原始凭据,生产写操作经过人工审查。

core · described · 对应问题 P1 原文依据

E1 失败案例 原文描述

执行型运维Agent可能利用环境能力绕过自身prompt中的操作限制。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 受信编排、microVM、secretless execution 原文描述

以单Agent隔离环境及调用代理隔开代码和原始凭据,生产写操作经过人工审查。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Where it breaks、当前与规划能力 编辑核验判断

已核对单Agent隔离和调用代理注入凭证;当前生产写操作仍需人审,输出secret scrubbing是内部pilot,风险分级自动放行尚在建设。 原文承认替代执行路径和MCP契约扩大仍可能绕过限制;不能将规划能力写成已交付保证。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Who spent all the tokens? Real-time, run-scoped cost control for AI agents

关注的问题

一次Agent任务跨进程、模型和子任务,按独立请求或进程计费会丢失统一预算。

作者的方法

以共享run账本累计消耗,在预算节点发出STEER或HALT并区分本地与严格共享计数。

  • 身份与权限
  • 工具与协议
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

一次Agent任务跨进程、模型和子任务,按独立请求或进程计费会丢失统一预算。 原文依据

还需处理的问题

分布式消耗计数可能滞后。 原文依据

02 文章用了什么方法

主要方法

以共享run账本累计消耗,在预算节点发出STEER或HALT并区分本地与严格共享计数。

回应的问题

一次Agent任务跨进程、模型和子任务,按独立请求或进程计费会丢失统一预算。

原文依据 原文依据

配套设计

区分默认本地最终一致计数与增加往返的严格共享读取。

回应的问题

分布式消耗计数可能滞后。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对共享run ledger及STEER/HALT;27次试验报告成本和预算内完成率,默认本地计数是最终一致,严格共享读取增加网络往返。 原文依据原文依据

这些结论有什么条件

成本限制不能判定答案是否正确;价值分配层尚未建成,不能将局部案例当作普遍收益。 原文依据

04 总结与启发

我们的理解与启发

围绕任务身份归集调用成本,将花费控制与结果价值判断分开。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 一次Agent任务跨进程、模型和子任务,按独立请求或进程计费会丢失统一预算。

primary 原文依据

P2 · 分布式消耗计数可能滞后。

secondary · ↳ P1 原文依据

D1 · 以共享run账本累计消耗,在预算节点发出STEER或HALT并区分本地与严格共享计数。

core · described · 对应问题 P1 原文依据

D2 · 区分默认本地最终一致计数与增加往返的严格共享读取。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 A gateway observes an isolated request. A run spans many. 原文描述

一次Agent任务跨进程、模型和子任务,按独立请求或进程计费会丢失统一预算。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Deciding out of band, enforcing in the path 原文描述

以共享run账本累计消耗,在预算节点发出STEER或HALT并区分本地与严格共享计数。 区分默认本地最终一致计数与增加往返的严格共享读取。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Running it against a real runaway、What this doesn't do 编辑核验判断

已核对共享run ledger及STEER/HALT;27次试验报告成本和预算内完成率,默认本地计数是最终一致,严格共享读取增加网络往返。 成本限制不能判定答案是否正确;价值分配层尚未建成,不能将局部案例当作普遍收益。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How we make AI coding more cost efficient without sacrificing task quality

关注的问题

逐条压短工具输出可能引发重新读取,反而增加整个编程任务的成本。

作者的方法

保留源码、压缩可恢复的噪声、去除无用行号,并在后台任务完成时直接返回结果。

  • 记忆与上下文
  • 工具与协议
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

逐条压短工具输出可能引发重新读取,反而增加整个编程任务的成本。 The local metric trap

02 文章用了什么方法

主要方法

保留源码、压缩可恢复的噪声、去除无用行号,并在后台任务完成时直接返回结果。

回应的问题

逐条压短工具输出可能引发重新读取,反而增加整个编程任务的成本。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对保留源码、可恢复压缩、去除无用行号及完成结果直接交付;四项A/B收益独立,不能简单相加。 原文依据Measure changes in context

这些结论有什么条件

RTK负面结果限定于测试集成;未检出质量下降不是证明所有任务等效,CLI与review收益也不同。 Measure changes in context

04 总结与启发

我们的理解与启发

按完整任务判断效率,优先去除重复传输与空转,保留所需信息。 原文依据Measure changes in context

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 逐条压短工具输出可能引发重新读取,反而增加整个编程任务的成本。

primary The local metric trap

D1 · 保留源码、压缩可恢复的噪声、去除无用行号,并在后台任务完成时直接返回结果。

core · described · 对应问题 P1 原文依据

E1 The local metric trap 原文描述

逐条压短工具输出可能引发重新读取,反而增加整个编程任务的成本。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Compress noise、Remove formatting、Deliver completed background work 原文描述

保留源码、压缩可恢复的噪声、去除无用行号,并在后台任务完成时直接返回结果。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Measure changes in context 编辑核验判断

已核对保留源码、可恢复压缩、去除无用行号及完成结果直接交付;四项A/B收益独立,不能简单相加。 RTK负面结果限定于测试集成;未检出质量下降不是证明所有任务等效,CLI与review收益也不同。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Running a Software Factory Efficiently at Uber Scale

关注的问题

大规模Agent使用增长使总账难解释,单价、上下文和调用轮数共同决定每个业务结果的成本。

作者的方法

把工具接入统一网关,以动态发现和Code Mode脚本压缩往返及轮询开销。

  • 工具与协议
  • 身份与权限
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

大规模Agent使用增长使总账难解释,单价、上下文和调用轮数共同决定每个业务结果的成本。 原文依据

02 文章用了什么方法

主要方法

把工具接入统一网关,以动态发现和Code Mode脚本压缩往返及轮询开销。

回应的问题

大规模Agent使用增长使总账难解释,单价、上下文和调用轮数共同决定每个业务结果的成本。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对统一网关、动态工具发现及脚本内轮询;code-mode表是在同一Claude Code会话内测得,非全公司任务收益。 原文依据How We Measure、Introduction

这些结论有什么条件

默认模型、400k压缩和缓存TTL反映Uber工作负载;文中明确说明成本收益不可直接外推。 How We Measure、Introduction

04 总结与启发

我们的理解与启发

以完成任务的成本和质量拆解优化,将工具目录与中间轮询移出持续模型上下文。 原文依据How We Measure、Introduction

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 大规模Agent使用增长使总账难解释,单价、上下文和调用轮数共同决定每个业务结果的成本。

primary 原文依据

D1 · 把工具接入统一网关,以动态发现和Code Mode脚本压缩往返及轮询开销。

core · described · 对应问题 P1 原文依据

E1 The Software Factory and Its Cost Equation 原文描述

大规模Agent使用增长使总账难解释,单价、上下文和调用轮数共同决定每个业务结果的成本。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Benchmark-Driven Model Selection、Executing MCP Tools via the Shell、Code-Mode 原文描述

把工具接入统一网关,以动态发现和Code Mode脚本压缩往返及轮询开销。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 How We Measure、Introduction 编辑核验判断

已核对统一网关、动态工具发现及脚本内轮询;code-mode表是在同一Claude Code会话内测得,非全公司任务收益。 默认模型、400k压缩和缓存TTL反映Uber工作负载;文中明确说明成本收益不可直接外推。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

An Organizational Second Brain: Building an AI That Learns From Experts

关注的问题

企业专家知识隐含在材料和判断过程中,每次检索再推导既慢又不一致,纠正也难持久化。

作者的方法

分离领域知识与recipe,用实际材料和专家反馈归因,再以最小编辑修订知识。

  • 记忆与上下文
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

企业专家知识隐含在材料和判断过程中,每次检索再推导既慢又不一致,纠正也难持久化。 原文依据

02 文章用了什么方法

主要方法

分离领域知识与recipe,用实际材料和专家反馈归因,再以最小编辑修订知识。

回应的问题

企业专家知识隐含在材料和判断过程中,每次检索再推导既慢又不一致,纠正也难持久化。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对知识文件与recipe分离、读取实际材料后归因、最小编辑和专家合并;零回归只指现有测试周期,结果未披露完整样本和比较细节。 原文依据Evaluation、Results

这些结论有什么条件

单合规领域六周实践与专家主观反馈支持可行性,不证明跨领域同等收益;知识正确与流程正确必须分别判断。 Evaluation、Results

04 总结与启发

我们的理解与启发

把事实立场和推理步骤分开维护,将专家纠正定位到具体文件与依赖。 原文依据Evaluation、Results

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 企业专家知识隐含在材料和判断过程中,每次检索再推导既慢又不一致,纠正也难持久化。

primary 原文依据

D1 · 分离领域知识与recipe,用实际材料和专家反馈归因,再以最小编辑修订知识。

core · described · 对应问题 P1 原文依据

E1 Building the Organizational Second Brain 原文描述

企业专家知识隐含在材料和判断过程中,每次检索再推导既慢又不一致,纠正也难持久化。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Expert Reasoning via Composable Recipes、Diagnosis、Compilation 原文描述

分离领域知识与recipe,用实际材料和专家反馈归因,再以最小编辑修订知识。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Evaluation、Results 编辑核验判断

已核对知识文件与recipe分离、读取实际材料后归因、最小编辑和专家合并;零回归只指现有测试周期,结果未披露完整样本和比较细节。 单合规领域六周实践与专家主观反馈支持可行性,不证明跨领域同等收益;知识正确与流程正确必须分别判断。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Automate planned lifecycle upgrades with AWS DevOps Agent and Kiro

关注的问题

计划内集群升级涉及发现、版本调查、代码修改和失败恢复,模型输出不足以直接触发部署。

作者的方法

先澄清升级spec,限制修改文件范围,以人工PR审查和有界恢复推进升级。

  • 文件与工件
  • 工具与协议
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

计划内集群升级涉及发现、版本调查、代码修改和失败恢复,模型输出不足以直接触发部署。 Phase 1–2

02 文章用了什么方法

主要方法

先澄清升级spec,限制修改文件范围,以人工PR审查和有界恢复推进升级。

回应的问题

计划内集群升级涉及发现、版本调查、代码修改和失败恢复,模型输出不足以直接触发部署。

原文依据 Phase 3、Phase 5

03 证据支持到哪里

从原文能确认什么

已核对spec消歧、单文件变更检查、人工PR和有界恢复;禁止Replace仍是人工检查,日常skill维护是best-effort。 Phase 3、Phase 5原文依据

这些结论有什么条件

文中的skill隔离依赖模型遵守指令;CloudFormation回滚不等于控制面版本已回退,部分可回滚条件没有自动检查。 原文依据

04 总结与启发

我们的理解与启发

在确定性流水线核对模型产物,将可自动判定的约束和需要人工判断的条件明确区分。 Phase 3、Phase 5原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 计划内集群升级涉及发现、版本调查、代码修改和失败恢复,模型输出不足以直接触发部署。

primary Phase 1–2

D1 · 先澄清升级spec,限制修改文件范围,以人工PR审查和有界恢复推进升级。

core · described · 对应问题 P1 Phase 3、Phase 5

E1 Phase 1–2 原文描述

计划内集群升级涉及发现、版本调查、代码修改和失败恢复,模型输出不足以直接触发部署。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Phase 3、Phase 5 原文描述

先澄清升级spec,限制修改文件范围,以人工PR审查和有界恢复推进升级。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Safety constraints、Keeping skills current 编辑核验判断

已核对spec消歧、单文件变更检查、人工PR和有界恢复;禁止Replace仍是人工检查,日常skill维护是best-effort。 文中的skill隔离依赖模型遵守指令;CloudFormation回滚不等于控制面版本已回退,部分可回滚条件没有自动检查。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

A guide to the anatomy of effective commerce agents

关注的问题

商业会话跨购物意图但共享用户和交易状态,分散委派容易丢失上下文,直接执行写操作又可能越权。

作者的方法

由单Agent按需加载skill,服务端生成稳定UI对象ID,先暂存变更再在apply时重验。

  • 文件与工件
  • 状态与恢复
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

商业会话跨购物意图但共享用户和交易状态,分散委派容易丢失上下文,直接执行写操作又可能越权。 Skills, not subagents

还需处理的问题

暂存的订单变更在提交时可能违反最新约束。 原文依据

02 文章用了什么方法

主要方法

由单Agent按需加载skill,服务端生成稳定UI对象ID,先暂存变更再在apply时重验。

回应的问题

商业会话跨购物意图但共享用户和交易状态,分散委派容易丢失上下文,直接执行写操作又可能越权。

原文依据 原文依据

配套设计

apply时重新读取并校验最终状态后提交。

回应的问题

暂存的订单变更在提交时可能违反最新约束。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对单Agent按需skill、服务端ID呈现、staged change和apply时重验;单Agent优势和异步记忆13%提升来自作者内部商业场景。 原文依据原文依据

这些结论有什么条件

不是排斥所有子Agent;自包含研究或独立合规会话仍适用,eager streaming会放弃服务端schema保证。 原文依据

04 总结与启发

我们的理解与启发

让模型组织交互、既有业务系统执行业务规则,对最终状态和批准对象实施约束。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 商业会话跨购物意图但共享用户和交易状态,分散委派容易丢失上下文,直接执行写操作又可能越权。

primary Skills, not subagents

P2 · 暂存的订单变更在提交时可能违反最新约束。

secondary · ↳ P1 原文依据

D1 · 由单Agent按需加载skill,服务端生成稳定UI对象ID,先暂存变更再在apply时重验。

core · described · 对应问题 P1 原文依据

D2 · apply时重新读取并校验最终状态后提交。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Skills, not subagents 原文描述

商业会话跨购物意图但共享用户和交易状态,分散委派容易丢失上下文,直接执行写操作又可能越权。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 The UI components are tools、Safety: enforcement lives in the harness 原文描述

由单Agent按需加载skill,服务端生成稳定UI对象ID,先暂存变更再在apply时重验。 apply时重新读取并校验最终状态后提交。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Writing memory、Capped transactions、各段评测说明 编辑核验判断

已核对单Agent按需skill、服务端ID呈现、staged change和apply时重验;单Agent优势和异步记忆13%提升来自作者内部商业场景。 不是排斥所有子Agent;自包含研究或独立合规会话仍适用,eager streaming会放弃服务端schema保证。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

What We Learned Putting A2A Into Production

关注的问题

独立部署的Agent需要跨边界传递任务、用户语义和答案来源,只有返回文本会丢失判断条件。

作者的方法

基于Agent Card路由并携带双方约定的私有DataContext,将错误和session世代显式传递。

  • 身份与权限
  • 工具与协议
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

独立部署的Agent需要跨边界传递任务、用户语义和答案来源,只有返回文本会丢失判断条件。 Why we chose A2A

02 文章用了什么方法

主要方法

基于Agent Card路由并携带双方约定的私有DataContext,将错误和session世代显式传递。

回应的问题

独立部署的Agent需要跨边界传递任务、用户语义和答案来源,只有返回文本会丢失判断条件。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Agent Card动态路由、私有DataContext扩展、错误事件显式文本及session epoch;context_id身份编码仅适用于双方受控实现。 原文依据原文依据

这些结论有什么条件

来源envelope格式错误时被静默丢弃,兼容优先并不保证每次回答都有来源;协议仍缺跨端会话滚转等能力。 原文依据

04 总结与启发

我们的理解与启发

跨Agent交接同时传递身份、来源新鲜度和可见失败,并区分协议能力与私有扩展。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 独立部署的Agent需要跨边界传递任务、用户语义和答案来源,只有返回文本会丢失判断条件。

primary Why we chose A2A

D1 · 基于Agent Card路由并携带双方约定的私有DataContext,将错误和session世代显式传递。

core · described · 对应问题 P1 原文依据

E1 Why we chose A2A 原文描述

独立部署的Agent需要跨边界传递任务、用户语义和答案来源,只有返回文本会丢失判断条件。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Carrying the asker's identity、Carrying provenance 原文描述

基于Agent Card路由并携带双方约定的私有DataContext,将错误和session世代显式传递。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Three things production broke、What we'd take to the spec 编辑核验判断

已核对Agent Card动态路由、私有DataContext扩展、错误事件显式文本及session epoch;context_id身份编码仅适用于双方受控实现。 来源envelope格式错误时被静默丢弃,兼容优先并不保证每次回答都有来源;协议仍缺跨端会话滚转等能力。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How we eliminated $1 million a year of wasted AI agent spend in one hour

关注的问题

工具参数含糊或返回原始异常,Agent反复猜测后仍可能完成任务,使额外花费隐藏在成功率中。

作者的方法

从会话trace定位七类工具缺陷,区分参数、返回体和等待过程造成的成本。

  • 工具与协议
  • 状态与恢复
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

工具参数含糊或返回原始异常,Agent反复猜测后仍可能完成任务,使额外花费隐藏在成功率中。 原文依据

02 文章用了什么方法

主要方法

从会话trace定位七类工具缺陷,区分参数、返回体和等待过程造成的成本。

回应的问题

工具参数含糊或返回原始异常,Agent反复猜测后仍可能完成任务,使额外花费隐藏在成功率中。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对七个工具缺陷和session级trace归因;年度49.9万美元token成本与120万美元生产力损失估算的口径必须区分,12000小时是等待时间估算。 原文依据缺陷成本表及错误质量表

这些结论有什么条件

年度数值由观察窗口外推,等待不等于全部可回收的人力;输入归一化也不能放松业务授权。 缺陷成本表及错误质量表

04 总结与启发

我们的理解与启发

将可恢复参数错误和真正失败分开,让工具契约与错误信息支持下一步判断。 原文依据缺陷成本表及错误质量表

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 工具参数含糊或返回原始异常,Agent反复猜测后仍可能完成任务,使额外花费隐藏在成功率中。

primary 原文依据

D1 · 从会话trace定位七类工具缺陷,区分参数、返回体和等待过程造成的成本。

core · described · 对应问题 P1 原文依据

E1 导言、How to monitor AI agent and MCP activity 原文描述

工具参数含糊或返回原始异常,Agent反复猜测后仍可能完成任务,使额外花费隐藏在成功率中。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 What the traces revealed、The real lesson 原文描述

从会话trace定位七类工具缺陷,区分参数、返回体和等待过程造成的成本。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 缺陷成本表及错误质量表 编辑核验判断

已核对七个工具缺陷和session级trace归因;年度49.9万美元token成本与120万美元生产力损失估算的口径必须区分,12000小时是等待时间估算。 年度数值由观察窗口外推,等待不等于全部可回收的人力;输入归一化也不能放松业务授权。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Building an Adaptive Agentic Cybersecurity System with NVIDIA Nemotron

关注的问题

生成检测规则既要命中观察到的攻击,也要避免只记住环境标识而不能迁移。

作者的方法

在专用模型之外加入schema grounding、lint、回测和独立评审等执行约束。

  • 观测与评测
  • 记忆与上下文
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

生成检测规则既要命中观察到的攻击,也要避免只记住环境标识而不能迁移。 原文依据

02 文章用了什么方法

主要方法

在专用模型之外加入schema grounding、lint、回测和独立评审等执行约束。

回应的问题

生成检测规则既要命中观察到的攻击,也要避免只记住环境标识而不能迁移。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对schema grounding、专用模型、lint、回测与独立评审;16.5%到41.9%的比较同时改变harness和模型栈,不能归因于单组件。 原文依据原文依据

这些结论有什么条件

只含一个场景族、八次新攻击及有限良性流量;三次harness失败保留了完整遥测,不代表生产误报率已获证明。 原文依据

04 总结与启发

我们的理解与启发

将语法有效、命中已见攻击、行为泛化和良性噪声作为不同证据层。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 生成检测规则既要命中观察到的攻击,也要避免只记住环境标识而不能迁移。

primary 原文依据

D1 · 在专用模型之外加入schema grounding、lint、回测和独立评审等执行约束。

core · described · 对应问题 P1 原文依据

E1 Turning offense and defense into a continuous learning loop 原文描述

生成检测规则既要命中观察到的攻击,也要避免只记住环境标识而不能迁移。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Specializing the defensive harness、Customizing Nemotron 原文描述

在专用模型之外加入schema grounding、lint、回测和独立评审等执行约束。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Evaluating the complete agent system、Interpreting the results 编辑核验判断

已核对schema grounding、专用模型、lint、回测与独立评审;16.5%到41.9%的比较同时改变harness和模型栈,不能归因于单组件。 只含一个场景族、八次新攻击及有限良性流量;三次harness失败保留了完整遥测,不代表生产误报率已获证明。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Closing the AI agent trust gap with graduated autonomy

关注的问题

固定授予权限无法反映Agent行为和版本变化,平均分还可能掩盖安全退化。

作者的方法

以独立安全下限和慢升快降的信任等级控制能力,调用前由进程外Cedar策略裁决。

  • 工具与协议
  • 身份与权限
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

固定授予权限无法反映Agent行为和版本变化,平均分还可能掩盖安全退化。 The agent trust gap

还需处理的问题

链式委派可能把低信任任务提升到更高能力。 原文依据

02 文章用了什么方法

主要方法

以独立安全下限和慢升快降的信任等级控制能力,调用前由进程外Cedar策略裁决。

回应的问题

固定授予权限无法反映Agent行为和版本变化,平均分还可能掩盖安全退化。

原文依据 原文依据

配套设计

以委派链中的最低信任等级计算有效权限。

回应的问题

链式委派可能把低信任任务提升到更高能力。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对独立安全下限、慢升快降、每调用读tier及进程外Cedar拒绝;委派有效tier取链上最小值。 原文依据原文依据

这些结论有什么条件

权重和分级是文章提供的起始模板,未给出生产效果对照;记录动作前状态不意味着所有外部副作用都可回滚。 原文依据

04 总结与启发

我们的理解与启发

把行为评分用于权限调整,关键限制仍由资源调用路径执行。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 固定授予权限无法反映Agent行为和版本变化,平均分还可能掩盖安全退化。

primary The agent trust gap

P2 · 链式委派可能把低信任任务提升到更高能力。

secondary · ↳ P1 原文依据

D1 · 以独立安全下限和慢升快降的信任等级控制能力,调用前由进程外Cedar策略裁决。

core · described · 对应问题 P1 原文依据

D2 · 以委派链中的最低信任等级计算有效权限。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 The agent trust gap 原文描述

固定授予权限无法反映Agent行为和版本变化,平均分还可能掩盖安全退化。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 The tier system、The enforcement layer 原文描述

以独立安全下限和慢升快降的信任等级控制能力,调用前由进程外Cedar策略裁决。 以委派链中的最低信任等级计算有效权限。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Production monitoring and recovery、Conclusion 编辑核验判断

已核对独立安全下限、慢升快降、每调用读tier及进程外Cedar拒绝;委派有效tier取链上最小值。 权重和分级是文章提供的起始模板,未给出生产效果对照;记录动作前状态不意味着所有外部副作用都可回滚。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Building Self-Correcting Memory in OpenWiki

关注的问题

代码演进后,Wiki仍可能沿用曾经正确的事实,单纯补充新知识无法识别旧结论失效。

作者的方法

把知识claim绑定来源版本,确定性扫描陈旧状态并在逐项核对后更新验证标记。

  • 记忆与上下文
  • 状态与恢复
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

代码演进后,Wiki仍可能沿用曾经正确的事实,单纯补充新知识无法识别旧结论失效。 原文依据

02 文章用了什么方法

主要方法

把知识claim绑定来源版本,确定性扫描陈旧状态并在逐项核对后更新验证标记。

回应的问题

代码演进后,Wiki仍可能沿用曾经正确的事实,单纯补充新知识无法识别旧结论失效。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对claim与证据版本绑定、确定性扫描和完整核对后标记verified;表中baseline stale为2000条的3.5%,正文又写80条,计数口径存在不一致。 原文依据原文依据

这些结论有什么条件

source变化只表示需要重新判断,不等于结论错误;未被访问的stale项可持续保留,系统不保证每轮全部修正。 原文依据

04 总结与启发

我们的理解与启发

把事实与版本化来源相连,让未知或过时状态持续可见直到原文重新核对。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 代码演进后,Wiki仍可能沿用曾经正确的事实,单纯补充新知识无法识别旧结论失效。

primary 原文依据

D1 · 把知识claim绑定来源版本,确定性扫描陈旧状态并在逐项核对后更新验证标记。

core · described · 对应问题 P1 原文依据

E1 Memory Has a Forgetting Problem 原文描述

代码演进后,Wiki仍可能沿用曾经正确的事实,单纯补充新知识无法识别旧结论失效。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Grounding、Knowing When Knowledge Goes Stale、Correcting Stale Claims 原文描述

把知识claim绑定来源版本,确定性扫描陈旧状态并在逐项核对后更新验证标记。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Evaluating the Ability to Forget 编辑核验判断

已核对claim与证据版本绑定、确定性扫描和完整核对后标记verified;表中baseline stale为2000条的3.5%,正文又写80条,计数口径存在不一致。 source变化只表示需要重新判断,不等于结论错误;未被访问的stale项可持续保留,系统不保证每轮全部修正。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Introducing Dogwood: runtime verification for AI agents

关注的问题

单次授权无法表达先审批后操作、累计额度和时间窗口内的行动约束。

作者的方法

在Cedar权限规则中加入过去时态条件,让策略同时考虑窗口内和当前请求。

  • 运行时与调度
  • 身份与权限
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

单次授权无法表达先审批后操作、累计额度和时间窗口内的行动约束。 导言、Temporal policies

02 文章用了什么方法

主要方法

在Cedar权限规则中加入过去时态条件,让策略同时考虑窗口内和当前请求。

回应的问题

单次授权无法表达先审批后操作、累计额度和时间窗口内的行动约束。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Dogwood在Cedar上加入过去时态条件,窗口可计入当前请求;只统计已完成响应会漏掉并发在途请求。 原文依据Temporal logic

这些结论有什么条件

状态和事件历史增加求值成本;时态条件尚不支持Cedar已有自动推理工具,示例的存在审批也不自动表达审批一次性消费。 Temporal logic

04 总结与启发

我们的理解与启发

将时序前提与当前请求共同判断,明确计量的是请求、完成结果还是独立对象。 原文依据Temporal logic

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 单次授权无法表达先审批后操作、累计额度和时间窗口内的行动约束。

primary 导言、Temporal policies

D1 · 在Cedar权限规则中加入过去时态条件,让策略同时考虑窗口内和当前请求。

core · described · 对应问题 P1 原文依据

E1 导言、Temporal policies 原文描述

单次授权无法表达先审批后操作、累计额度和时间窗口内的行动约束。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Looking back、Summing、Rate limiting requests vs. responses 原文描述

在Cedar权限规则中加入过去时态条件,让策略同时考虑窗口内和当前请求。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Temporal logic 编辑核验判断

已核对Dogwood在Cedar上加入过去时态条件,窗口可计入当前请求;只统计已完成响应会漏掉并发在途请求。 状态和事件历史增加求值成本;时态条件尚不支持Cedar已有自动推理工具,示例的存在审批也不自动表达审批一次性消费。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Temporal Agent Harness: An early look at durable agent infrastructure

关注的问题

业务Agent的会话跨工具、人工等待和进程故障,内层模型循环缺少统一持久控制。

作者的方法

外层Workflow承载持久状态和审批,内层Agent SDK执行推理,通过统一事件接口连接。

  • 状态与恢复
  • 工具与协议
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

业务Agent的会话跨工具、人工等待和进程故障,内层模型循环缺少统一持久控制。 The Temporal Agent Harness

02 文章用了什么方法

主要方法

外层Workflow承载持久状态和审批,内层Agent SDK执行推理,通过统一事件接口连接。

回应的问题

业务Agent的会话跨工具、人工等待和进程故障,内层模型循环缺少统一持久控制。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Workflow承载Agent、持久approval、typed operation和统一AgentEvent;当前支持三种内层SDK。 原文依据What we're sharing today

这些结论有什么条件

作者明确阶段早于public preview,API仍会变化;持久恢复不能替代外部副作用自身的幂等与权限设计。 What we're sharing today

04 总结与启发

我们的理解与启发

分离内层推理循环与外层业务生命周期,让控制和状态具备独立接口。 原文依据What we're sharing today

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 业务Agent的会话跨工具、人工等待和进程故障,内层模型循环缺少统一持久控制。

primary The Temporal Agent Harness

D1 · 外层Workflow承载持久状态和审批,内层Agent SDK执行推理,通过统一事件接口连接。

core · described · 对应问题 P1 原文依据

E1 The Temporal Agent Harness 原文描述

业务Agent的会话跨工具、人工等待和进程故障,内层模型循环缺少统一持久控制。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Durable execution、Controls around tool calls、AgentEvent 原文描述

外层Workflow承载持久状态和审批,内层Agent SDK执行推理,通过统一事件接口连接。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 What we're sharing today 编辑核验判断

已核对Workflow承载Agent、持久approval、typed operation和统一AgentEvent;当前支持三种内层SDK。 作者明确阶段早于public preview,API仍会变化;持久恢复不能替代外部副作用自身的幂等与权限设计。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Scaling patterns for self-organizing multi-agent clusters with Kiro

关注的问题

分布式Agent讨论既要交换进展,也要避免全可见导致过早共识与上下文膨胀。

作者的方法

各Agent维护追加日志并只观察有限邻居,以每轮新会话和共享工件协调工作。

  • 文件与工件
  • 状态与恢复
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

分布式Agent讨论既要交换进展,也要避免全可见导致过早共识与上下文膨胀。 The pattern

02 文章用了什么方法

主要方法

各Agent维护追加日志并只观察有限邻居,以每轮新会话和共享工件协调工作。

回应的问题

分布式Agent讨论既要交换进展,也要避免全可见导致过早共识与上下文膨胀。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对每Agent追加日志、有限邻居和每轮新会话;最大实际规模184个Agent跨11集群,千级传播表是推算。 原文依据Where it breaks、规模说明

这些结论有什么条件

局部每轮读取有界不等于整体通信或达成共识成本不增长;共享产物的一致性不能由日志CRDT性质自动推出。 Where it breaks、规模说明

04 总结与启发

我们的理解与启发

按探索与收敛阶段调节可见范围,并把旧任务状态与新运行明确隔离。 原文依据Where it breaks、规模说明

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 分布式Agent讨论既要交换进展,也要避免全可见导致过早共识与上下文膨胀。

primary The pattern

D1 · 各Agent维护追加日志并只观察有限邻居,以每轮新会话和共享工件协调工作。

core · described · 对应问题 P1 原文依据

E1 The pattern 原文描述

分布式Agent讨论既要交换进展,也要避免全可见导致过早共识与上下文膨胀。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Three ways to answer whose work do I read 原文描述

各Agent维护追加日志并只观察有限邻居,以每轮新会话和共享工件协调工作。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Where it breaks、规模说明 编辑核验判断

已核对每Agent追加日志、有限邻居和每轮新会话;最大实际规模184个Agent跨11集群,千级传播表是推算。 局部每轮读取有界不等于整体通信或达成共识成本不增长;共享产物的一致性不能由日志CRDT性质自动推出。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Staying Ahead of Adversarial AI Through Agentic Source Code Review

关注的问题

源码漏洞判断需要可达性和业务威胁模型,孤立模式匹配容易产生无效发现。

作者的方法

人审威胁模型后拆分入口分析,独立核验漏洞假设并匹配精确漏洞条件。

  • 文件与工件
  • 安全与隔离
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

源码漏洞判断需要可达性和业务威胁模型,孤立模式匹配容易产生无效发现。 原文依据

02 文章用了什么方法

主要方法

人审威胁模型后拆分入口分析,独立核验漏洞假设并匹配精确漏洞条件。

回应的问题

源码漏洞判断需要可达性和业务威胁模型,孤立模式匹配容易产生无效发现。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对先人审威胁模型再并行入口分析、独立假设评审及精确漏洞匹配;合成基准注入点由专家确认可利用。 原文依据原文依据

这些结论有什么条件

多模型高温判断不等于独立客观证据;正文未披露足够定量数据证明泛化检出率,仍依赖专家复核。 原文依据

04 总结与启发

我们的理解与启发

把发现、反证和威胁模型适用性分开,保留从入口到危险操作的路径。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 源码漏洞判断需要可达性和业务威胁模型,孤立模式匹配容易产生无效发现。

primary 原文依据

D1 · 人审威胁模型后拆分入口分析,独立核验漏洞假设并匹配精确漏洞条件。

core · described · 对应问题 P1 原文依据

E1 Architecting the Pipeline、Threat Modeling 原文描述

源码漏洞判断需要可达性和业务威胁模型,孤立模式匹配容易产生无效发现。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Entry Point Discovery、Context Enrichment、Hypothesis Validation 原文描述

人审威胁模型后拆分入口分析,独立核验漏洞假设并匹配精确漏洞条件。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Benchmark Targets、Benchmark Grading 编辑核验判断

已核对先人审威胁模型再并行入口分析、独立假设评审及精确漏洞匹配;合成基准注入点由专家确认可利用。 多模型高温判断不等于独立客观证据;正文未披露足够定量数据证明泛化检出率,仍依赖专家复核。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Route AI Agent Workloads Across Models with NVIDIA NeMo Switchyard

关注的问题

不同模型在任务阶段与成本上各有优势,固定选最强模型不一定得到最佳结果成本。

作者的方法

用语义model target与会话亲和选择模型,遇到指定错误信号再升级。

  • 状态与恢复
  • 工具与协议
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

不同模型在任务阶段与成本上各有优势,固定选最强模型不一定得到最佳结果成本。 原文依据

02 文章用了什么方法

主要方法

用语义model target与会话亲和选择模型,遇到指定错误信号再升级。

回应的问题

不同模型在任务阶段与成本上各有优势,固定选最强模型不一定得到最佳结果成本。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对语义model target、会话亲和及错误信号升级;74%降本伴随约6个百分点准确率下降,不能写成无损降本。 原文依据Improving agent efficiency

这些结论有什么条件

收益限定各伙伴任务集和组合;prefill路由需要模型内部状态与训练,不是所有API模型都可直接使用。 Improving agent efficiency

04 总结与启发

我们的理解与启发

将路由策略和供应商调用分开,按任务完成质量解释成本取舍。 原文依据Improving agent efficiency

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 不同模型在任务阶段与成本上各有优势,固定选最强模型不一定得到最佳结果成本。

primary 原文依据

D1 · 用语义model target与会话亲和选择模型,遇到指定错误信号再升级。

core · described · 对应问题 P1 原文依据

E1 How model routers make decisions 原文描述

不同模型在任务阶段与成本上各有优势,固定选最强模型不一定得到最佳结果成本。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 How NeMo Switchyard enables routing、Stage router、Escalation router 原文描述

用语义model target与会话亲和选择模型,遇到指定错误信号再升级。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Improving agent efficiency 编辑核验判断

已核对语义model target、会话亲和及错误信号升级;74%降本伴随约6个百分点准确率下降,不能写成无损降本。 收益限定各伙伴任务集和组合;prefill路由需要模型内部状态与训练,不是所有API模型都可直接使用。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How we build an autonomous SRE Agent for Kubernetes Deployments

关注的问题

周期健康检查不需要每次启动完整多Agent调查,而写操作需要明确可审阅范围。

作者的方法

用Python采集加单次模型判断完成健康检查,写能力集中在受RBAC和人审约束的executor。

  • 工具与协议
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

周期健康检查不需要每次启动完整多Agent调查,而写操作需要明确可审阅范围。 Part 2: What we built

02 文章用了什么方法

主要方法

用Python采集加单次模型判断完成健康检查,写能力集中在受RBAC和人审约束的executor。

回应的问题

周期健康检查不需要每次启动完整多Agent调查,而写操作需要明确可审阅范围。

原文依据 Part 3: How We Built It

03 证据支持到哪里

从原文能确认什么

已核对Python采集加单Haiku调用、change-executor独占写工具和RBAC;95–99%节省只指健康检查,不是所有SRE任务。 Part 3: How We Built It原文依据

这些结论有什么条件

初版定时collector漏采利用率导致结构性答不出问题;简化循环是否足够取决于实际输入覆盖。 原文依据

04 总结与启发

我们的理解与启发

让固定监测走直接采集,复杂诊断再进入Agent;批准项尽量小且可理解。 Part 3: How We Built It原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 周期健康检查不需要每次启动完整多Agent调查,而写操作需要明确可审阅范围。

primary Part 2: What we built

D1 · 用Python采集加单次模型判断完成健康检查,写能力集中在受RBAC和人审约束的executor。

core · described · 对应问题 P1 Part 3: How We Built It

E1 Part 2: What we built 原文描述

周期健康检查不需要每次启动完整多Agent调查,而写操作需要明确可审阅范围。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Part 3: How We Built It 原文描述

用Python采集加单次模型判断完成健康检查,写能力集中在受RBAC和人审约束的executor。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 What the traces caught、LangSmith Engine 编辑核验判断

已核对Python采集加单Haiku调用、change-executor独占写工具和RBAC;95–99%节省只指健康检查,不是所有SRE任务。 初版定时collector漏采利用率导致结构性答不出问题;简化循环是否足够取决于实际输入覆盖。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

TOLAP: Closing the data-object security gap in AI agent architectures

关注的问题

工具获准访问某数据源后,仍可能返回调用者无权读取的行或字段。

作者的方法

把规则按最严格语义合并并签名,由资源工具wrapper核对时效、上下文与请求。

  • 工具与协议
  • 文件与工件
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

工具获准访问某数据源后,仍可能返回调用者无权读取的行或字段。 原文依据

02 文章用了什么方法

主要方法

把规则按最严格语义合并并签名,由资源工具wrapper核对时效、上下文与请求。

回应的问题

工具获准访问某数据源后,仍可能返回调用者无权读取的行或字段。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对最严格合并、签名有效期context及资源侧wrapper;安全前提是该工具确为数据源唯一配置通路。 原文依据Security properties

这些结论有什么条件

签名证明完整性而非策略本身正确,过期时间也不自动阻止有效期内重复使用;跨源覆盖依赖各wrapper实现。 Security properties

04 总结与启发

我们的理解与启发

在数据离开权威源之前执行对象级授权,避免靠模型过滤已拿到的敏感内容。 原文依据Security properties

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 工具获准访问某数据源后,仍可能返回调用者无权读取的行或字段。

primary 原文依据

D1 · 把规则按最严格语义合并并签名,由资源工具wrapper核对时效、上下文与请求。

core · described · 对应问题 P1 原文依据

E1 Why traditional access models fall short 原文描述

工具获准访问某数据源后,仍可能返回调用者无权读取的行或字段。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Three principles、Five components 原文描述

把规则按最严格语义合并并签名,由资源工具wrapper核对时效、上下文与请求。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Security properties 编辑核验判断

已核对最严格合并、签名有效期context及资源侧wrapper;安全前提是该工具确为数据源唯一配置通路。 签名证明完整性而非策略本身正确,过期时间也不自动阻止有效期内重复使用;跨源覆盖依赖各wrapper实现。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Do more with less: How GKE can reduce your cost per agent by 75%

关注的问题

大量间歇工作Agent长期占用独立运行环境,空闲资源使每Agent成本偏高。

作者的方法

组合gVisor隔离、预热与快照释放闲置资源,提高特定间歇负载的单节点密度。

  • 状态与恢复
  • 安全与隔离
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

大量间歇工作Agent长期占用独立运行环境,空闲资源使每Agent成本偏高。 原文依据

02 文章用了什么方法

主要方法

组合gVisor隔离、预热与快照释放闲置资源,提高特定间歇负载的单节点密度。

回应的问题

大量间歇工作Agent长期占用独立运行环境,空闲资源使每Agent成本偏高。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对gVisor降低固定开销与snapshot释放闲置资源;61、88、133、274是不同配置下的单节点容量。 原文依据部署密度和启动时延说明

这些结论有什么条件

75%是带间歇活动和可接受启动等待的上限案例;与microVM相比的密度证据不能证明隔离机制等价。 部署密度和启动时延说明

04 总结与启发

我们的理解与启发

按延迟要求组合预热、挂起和排队,将密度收益与同时唤醒风险一起考虑。 原文依据部署密度和启动时延说明

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 大量间歇工作Agent长期占用独立运行环境,空闲资源使每Agent成本偏高。

primary 原文依据

D1 · 组合gVisor隔离、预热与快照释放闲置资源,提高特定间歇负载的单节点密度。

core · described · 对应问题 P1 原文依据

E1 Baseline: Running OpenClaw on microVMs 原文描述

大量间歇工作Agent长期占用独立运行环境,空闲资源使每Agent成本偏高。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Optimization 1、Optimization 2 原文描述

组合gVisor隔离、预热与快照释放闲置资源,提高特定间歇负载的单节点密度。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 部署密度和启动时延说明 编辑核验判断

已核对gVisor降低固定开销与snapshot释放闲置资源;61、88、133、274是不同配置下的单节点容量。 75%是带间歇活动和可接受启动等待的上限案例;与microVM相比的密度证据不能证明隔离机制等价。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Your agent needs a computer, not a container — introducing @cloudflare/computer

关注的问题

每个Agent长期占用容器开销较高,但任务又需要共享文件和不同执行能力。

作者的方法

以SQLite文件系统衔接isolate与容器FUSE,用统一exec入口调度不同执行环境。

  • 文件与工件
  • 工具与协议
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

每个Agent长期占用容器开销较高,但任务又需要共享文件和不同执行能力。 原文依据

02 文章用了什么方法

主要方法

以SQLite文件系统衔接isolate与容器FUSE,用统一exec入口调度不同执行环境。

回应的问题

每个Agent长期占用容器开销较高,但任务又需要共享文件和不同执行能力。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对SQLite工作区、isolate绑定与容器FUSE、统一exec backend;工具描述引导模型选择环境。 原文依据What's next

这些结论有什么条件

早期preview,容器少于10%工作是目标而非已达到的普遍结果;共享接口不等于各后端能力一致。 What's next

04 总结与启发

我们的理解与启发

以持久工作区为中心,按工作需要附加轻重不同的执行环境。 原文依据What's next

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 每个Agent长期占用容器开销较高,但任务又需要共享文件和不同执行能力。

primary 原文依据

D1 · 以SQLite文件系统衔接isolate与容器FUSE,用统一exec入口调度不同执行环境。

core · described · 对应问题 P1 原文依据

E1 Changing how agents are built 原文描述

每个Agent长期占用容器开销较高,但任务又需要共享文件和不同执行能力。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 A shared filesystem、How it works 原文描述

以SQLite文件系统衔接isolate与容器FUSE,用统一exec入口调度不同执行环境。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 What's next 编辑核验判断

已核对SQLite工作区、isolate绑定与容器FUSE、统一exec backend;工具描述引导模型选择环境。 早期preview,容器少于10%工作是目标而非已达到的普遍结果;共享接口不等于各后端能力一致。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Automating cross-repo documentation with GitHub Agentic Workflows

关注的问题

产品和文档分属仓库,文档往往滞后,而直接给Agent跨仓写权限扩大风险。

作者的方法

只读Agent产出变更意图,受限handler按milestone分支关系创建草稿PR。

  • 文件与工件
  • 状态与恢复
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

产品和文档分属仓库,文档往往滞后,而直接给Agent跨仓写权限扩大风险。 The constraint

还需处理的问题

不同发布分支需要不同的文档目标。 原文依据

02 文章用了什么方法

主要方法

只读Agent产出变更意图,受限handler按milestone分支关系创建草稿PR。

回应的问题

产品和文档分属仓库,文档往往滞后,而直接给Agent跨仓写权限扩大风险。

原文依据 原文依据

配套设计

通过milestone与分支映射选择草稿PR目标。

回应的问题

不同发布分支需要不同的文档目标。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对只读Agent输出意图、受限handler建草稿PR及milestone分支映射;82篇合并反映观察窗口,不能证明遗漏率为零。 原文依据原文依据

这些结论有什么条件

早版有9/69关闭,后续窗口不能掩盖不同版本;合并率也不等于内容无需编辑或质量普遍可靠。 原文依据

04 总结与启发

我们的理解与启发

把生成内容与持权发布分开,让源变更和领域评审人跟随文档草稿。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 产品和文档分属仓库,文档往往滞后,而直接给Agent跨仓写权限扩大风险。

primary The constraint

P2 · 不同发布分支需要不同的文档目标。

secondary · ↳ P1 原文依据

D1 · 只读Agent产出变更意图,受限handler按milestone分支关系创建草稿PR。

core · described · 对应问题 P1 原文依据

D2 · 通过milestone与分支映射选择草稿PR目标。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 The constraint 原文描述

产品和文档分属仓库,文档往往滞后,而直接给Agent跨仓写权限扩大风险。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 The end-to-end pipeline、The safe-outputs contract 原文描述

只读Agent产出变更意图,受限handler按milestone分支关系创建草稿PR。 通过milestone与分支映射选择草稿PR目标。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 By the numbers、What worked/what didn't 编辑核验判断

已核对只读Agent输出意图、受限handler建草稿PR及milestone分支映射;82篇合并反映观察窗口,不能证明遗漏率为零。 早版有9/69关闭,后续窗口不能掩盖不同版本;合并率也不等于内容无需编辑或质量普遍可靠。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How Stripe Built Kai, its Company-Wide AI Agent, on Deep Agents

关注的问题

企业Agent需要跨会话文件、隔离代码和大量内部能力,全部前置上下文会降低质量。

作者的方法

以S3虚拟文件系统同步沙箱工作区,先发现skill再加载其允许的工具集合。

  • 文件与工件
  • 工具与协议
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

企业Agent需要跨会话文件、隔离代码和大量内部能力,全部前置上下文会降低质量。 原文依据

02 文章用了什么方法

主要方法

以S3虚拟文件系统同步沙箱工作区,先发现skill再加载其允许的工具集合。

回应的问题

企业Agent需要跨会话文件、隔离代码和大量内部能力,全部前置上下文会降低质量。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对S3虚拟文件系统sync-in/out、沙箱工具及skill allowedTools两阶段加载;超过150技能时曾出现质量退化。 原文依据技能规模说明

这些结论有什么条件

一人一周是已有内部基础上的初版开发故事,不是从零建设企业平台的全部成本;加载工具列表本身不等于授权。 技能规模说明

04 总结与启发

我们的理解与启发

复用通用循环,在企业层维护身份、文件与技能目录,动态缩小可见上下文。 原文依据技能规模说明

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 企业Agent需要跨会话文件、隔离代码和大量内部能力,全部前置上下文会降低质量。

primary 原文依据

D1 · 以S3虚拟文件系统同步沙箱工作区,先发现skill再加载其允许的工具集合。

core · described · 对应问题 P1 原文依据

E1 Building an in-house agent harness 原文描述

企业Agent需要跨会话文件、隔离代码和大量内部能力,全部前置上下文会降低质量。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 What made Kai production-ready、Skills 原文描述

以S3虚拟文件系统同步沙箱工作区,先发现skill再加载其允许的工具集合。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 技能规模说明 编辑核验判断

已核对S3虚拟文件系统sync-in/out、沙箱工具及skill allowedTools两阶段加载;超过150技能时曾出现质量退化。 一人一周是已有内部基础上的初版开发故事,不是从零建设企业平台的全部成本;加载工具列表本身不等于授权。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How Apollo Rebuilt Its AI Assistant on Deep Agents to Power the Full GTM Loop

关注的问题

每个新业务都新增子Agent与路由,产生开发成本和反复确认,难支持跨GTM目标。

作者的方法

将层级主管改为扁平skill计划,并用分层rubric、双人评价和生产反馈改进系统。

  • 观测与评测
  • 工具与协议
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

每个新业务都新增子Agent与路由,产生开发成本和反复确认,难支持跨GTM目标。 The Challenge

02 文章用了什么方法

主要方法

将层级主管改为扁平skill计划,并用分层rubric、双人评价和生产反馈改进系统。

回应的问题

每个新业务都新增子Agent与路由,产生开发成本和反复确认,难支持跨GTM目标。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对扁平skill计划和六层评估,从50–200输出双人评审到生产反馈;80–85%开发投入下降为团队陈述。 原文依据原文依据

这些结论有什么条件

未披露等预算对照,不能据此认定所有supervisor架构都不适合;无头扩展仍需要业务权限边界。 原文依据

04 总结与启发

我们的理解与启发

按用户目标组织可组合能力,用同一质量定义连接上线前检查与线上反馈。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 每个新业务都新增子Agent与路由,产生开发成本和反复确认,难支持跨GTM目标。

primary The Challenge

D1 · 将层级主管改为扁平skill计划,并用分层rubric、双人评价和生产反馈改进系统。

core · described · 对应问题 P1 原文依据

E1 The Challenge 原文描述

每个新业务都新增子Agent与路由,产生开发成本和反复确认,难支持跨GTM目标。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 From Supervisor Hierarchies to Deep Agents 原文描述

将层级主管改为扁平skill计划,并用分层rubric、双人评价和生产反馈改进系统。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 AI Watchtower、One Assistant Across Every Surface 编辑核验判断

已核对扁平skill计划和六层评估,从50–200输出双人评审到生产反馈;80–85%开发投入下降为团队陈述。 未披露等预算对照,不能据此认定所有supervisor架构都不适合;无头扩展仍需要业务权限边界。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How we built LangChain’s agent-first data stack

关注的问题

企业数据问答不仅缺表信息,还缺统一指标定义、权威来源和团队语义。

作者的方法

把dbt逻辑、语义层和版本化guide用于数据代理,由数据团队维护权威认可标记。

  • 记忆与上下文
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

企业数据问答不仅缺表信息,还缺统一指标定义、权威来源和团队语义。 Where we started

02 文章用了什么方法

主要方法

把dbt逻辑、语义层和版本化guide用于数据代理,由数据团队维护权威认可标记。

回应的问题

企业数据问答不仅缺表信息,还缺统一指标定义、权威来源和团队语义。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对dbt逻辑、语义层、Git版本化guide和仅数据团队可维护的endorsement;100%使用包含70%只读用户。 原文依据原文依据

这些结论有什么条件

采用率不是所有人都在使用Agent,也不证明回答正确率;作者明确底层模型混乱不能靠语义层补救。 原文依据

04 总结与启发

我们的理解与启发

将数据结构、指标口径、业务解释和信任声明分层维护,按失败类型更新对应层。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 企业数据问答不仅缺表信息,还缺统一指标定义、权威来源和团队语义。

primary Where we started

D1 · 把dbt逻辑、语义层和版本化guide用于数据代理,由数据团队维护权威认可标记。

core · described · 对应问题 P1 原文依据

E1 Where we started 原文描述

企业数据问答不仅缺表信息,还缺统一指标定义、权威来源和团队语义。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 The semantic model、Capturing business context、Endorsements 原文描述

把dbt逻辑、语义层和版本化guide用于数据代理,由数据团队维护权威认可标记。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 What changed after we migrated、How we improve the system 编辑核验判断

已核对dbt逻辑、语义层、Git版本化guide和仅数据团队可维护的endorsement;100%使用包含70%只读用户。 采用率不是所有人都在使用Agent,也不证明回答正确率;作者明确底层模型混乱不能靠语义层补救。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Build Production-Ready Agents with the GitHub Copilot Harness and Agent Framework

关注的问题

已有Copilot能力需要进入统一Agent Framework接口,同时保留其原生工具循环和审批责任。

作者的方法

由Copilot SDK掌握内层代理循环,框架提供外层接口,工具执行接入SDK审批hook。

  • 工具与协议
  • 状态与恢复
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

已有Copilot能力需要进入统一Agent Framework接口,同时保留其原生工具循环和审批责任。 原文依据

02 文章用了什么方法

主要方法

由Copilot SDK掌握内层代理循环,框架提供外层接口,工具执行接入SDK审批hook。

回应的问题

已有Copilot能力需要进入统一Agent Framework接口,同时保留其原生工具循环和审批责任。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Copilot拥有内循环、框架提供外接口,原生工具审批通过SDK pre-tool-use;示例明确使用approve_all/ApproveOnce。 原文依据Native tool approval及代码示例

这些结论有什么条件

文章的默认监督描述不能覆盖示例中主动全放行配置;自定义hook可能绕过默认审批且仅给警告。 Native tool approval及代码示例

04 总结与启发

我们的理解与启发

在拥有实际工具循环的一层落实审批,再通过统一接口组合其他应用组件。 原文依据Native tool approval及代码示例

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 已有Copilot能力需要进入统一Agent Framework接口,同时保留其原生工具循环和审批责任。

primary 原文依据

D1 · 由Copilot SDK掌握内层代理循环,框架提供外层接口,工具执行接入SDK审批hook。

core · described · 对应问题 P1 原文依据

E1 What is the GitHub Copilot Agent 原文描述

已有Copilot能力需要进入统一Agent Framework接口,同时保留其原生工具循环和审批责任。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Manage sessions、Built for production 原文描述

由Copilot SDK掌握内层代理循环,框架提供外层接口,工具执行接入SDK审批hook。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Native tool approval及代码示例 编辑核验判断

已核对Copilot拥有内循环、框架提供外接口,原生工具审批通过SDK pre-tool-use;示例明确使用approve_all/ApproveOnce。 文章的默认监督描述不能覆盖示例中主动全放行配置;自定义hook可能绕过默认审批且仅给警告。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Zero risk isn't the job: a CISO's guide to agentic AI

关注的问题

同一权限下模型升级也可能发现新的委派路径,按旧模型能力估算风险会失效。

作者的方法

围绕输入来源、动作身份、影响范围和可观测性分析代理系统的实际授权路径。

  • 身份与权限
  • 安全与隔离
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

同一权限下模型升级也可能发现新的委派路径,按旧模型能力估算风险会失效。 原文依据

02 文章用了什么方法

主要方法

围绕输入来源、动作身份、影响范围和可观测性分析代理系统的实际授权路径。

回应的问题

同一权限下模型升级也可能发现新的委派路径,按旧模型能力估算风险会失效。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对内容来源、操作身份、影响范围和可观察性四维;案例通过Slack间接请求代码Agent,最终代码仍经人审。 原文依据原文依据

这些结论有什么条件

内部内容不是天然可信,原文自己限定攻击需内部人员或被盗账户;这是治理经验而非安全效果定量比较。 原文依据

04 总结与启发

我们的理解与启发

依据可用能力与资源边界治理,并把间接委派纳入身份和影响范围。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 同一权限下模型升级也可能发现新的委派路径,按旧模型能力估算风险会失效。

primary 原文依据

D1 · 围绕输入来源、动作身份、影响范围和可观测性分析代理系统的实际授权路径。

core · described · 对应问题 P1 原文依据

E1 Four questions、The agentic identity spectrum 原文描述

同一权限下模型升级也可能发现新的委派路径,按旧模型能力估算风险会失效。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Case study: an incident response agent 原文描述

围绕输入来源、动作身份、影响范围和可观测性分析代理系统的实际授权路径。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Design your security protocol for evolving model intelligence 编辑核验判断

已核对内容来源、操作身份、影响范围和可观察性四维;案例通过Slack间接请求代码Agent,最终代码仍经人审。 内部内容不是天然可信,原文自己限定攻击需内部人员或被盗账户;这是治理经验而非安全效果定量比较。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How Anthropic runs large-scale code migrations with Claude Code

关注的问题

跨语言迁移涉及隐含契约和架构差异,逐文件翻译会扩散相同错误。

作者的方法

先建立迁移规则和缺口清单,再按依赖翻译,分别核对编译、运行与行为。

  • 文件与工件
  • 状态与恢复
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

跨语言迁移涉及隐含契约和架构差异,逐文件翻译会扩散相同错误。 Step 1

02 文章用了什么方法

主要方法

先建立迁移规则和缺口清单,再按依赖翻译,分别核对编译、运行与行为。

回应的问题

跨语言迁移涉及隐含契约和架构差异,逐文件翻译会扩散相同错误。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对先规则与缺口清单,再按依赖翻译并分别核对编译、运行和行为;现成starter kit不是两次真实迁移使用的原样脚本。 原文依据迁移结构与编译成本的差异说明

这些结论有什么条件

结构保留与重新设计不适用同一种对照;是否把编译放进内循环取决于编译成本,文件存在仅表示翻译阶段产物存在。 迁移结构与编译成本的差异说明

04 总结与启发

我们的理解与启发

把重复发现转成规则修订,分开判断语法通过、可运行和行为一致。 原文依据迁移结构与编译成本的差异说明

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 跨语言迁移涉及隐含契约和架构差异,逐文件翻译会扩散相同错误。

primary Step 1

D1 · 先建立迁移规则和缺口清单,再按依赖翻译,分别核对编译、运行与行为。

core · described · 对应问题 P1 原文依据

E1 Step 1 原文描述

跨语言迁移涉及隐含契约和架构差异,逐文件翻译会扩散相同错误。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Rulebook、Dependency map、Gap inventory、Steps 2–6 原文描述

先建立迁移规则和缺口清单,再按依赖翻译,分别核对编译、运行与行为。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 迁移结构与编译成本的差异说明 编辑核验判断

已核对先规则与缺口清单,再按依赖翻译并分别核对编译、运行和行为;现成starter kit不是两次真实迁移使用的原样脚本。 结构保留与重新设计不适用同一种对照;是否把编译放进内循环取决于编译成本,文件存在仅表示翻译阶段产物存在。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Agentic retrieval for Amazon Bedrock Managed Knowledge Base

关注的问题

多跳问题需要从前次结果提出下一次查询,单次检索容易缺少证据链。

作者的方法

组合投机检索与多轮查询规划,最终返回去重片段并保留完整检索轨迹。

  • 记忆与上下文
  • 观测与评测
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

多跳问题需要从前次结果提出下一次查询,单次检索容易缺少证据链。 原文依据

02 文章用了什么方法

主要方法

组合投机检索与多轮查询规划,最终返回去重片段并保留完整检索轨迹。

回应的问题

多跳问题需要从前次结果提出下一次查询,单次检索容易缺少证据链。

原文依据 What agentic retrieval is

03 证据支持到哪里

从原文能确认什么

已核对speculative retrieval、规划/正文扩展和最终结果去重;初次投机检索不计maxAgentIteration,trace保留重复过程。 What agentic retrieval is原文依据

这些结论有什么条件

MuSiQue召回提升不是最终答案准确率;更多轮数增加成本,guardrail只支持BLOCK不支持MASK。 原文依据

04 总结与启发

我们的理解与启发

将子查询过程和最终证据集分开记录,按问题复杂度理解额外检索价值。 What agentic retrieval is原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 多跳问题需要从前次结果提出下一次查询,单次检索容易缺少证据链。

primary 原文依据

D1 · 组合投机检索与多轮查询规划,最终返回去重片段并保留完整检索轨迹。

core · described · 对应问题 P1 What agentic retrieval is

E1 Why single-shot retrieval falls short 原文描述

多跳问题需要从前次结果提出下一次查询,单次检索容易缺少证据链。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 What agentic retrieval is 原文描述

组合投机检索与多轮查询规划,最终返回去重片段并保留完整检索轨迹。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 How agentic retrieval performs、Security governance 编辑核验判断

已核对speculative retrieval、规划/正文扩展和最终结果去重;初次投机检索不计maxAgentIteration,trace保留重复过程。 MuSiQue召回提升不是最终答案准确率;更多轮数增加成本,guardrail只支持BLOCK不支持MASK。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How to Run an Autoresearch Workflow with RL Agent Skills and NVIDIA NeMo

关注的问题

长研究会话容易遗失目标、环境惯例和停止条件,导致低信息量的反复尝试。

作者的方法

以行为规范、会话记忆和autoresearch三个skill分别管理会话规则、累积信息和研究循环。

  • 状态与恢复
  • 文件与工件
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

长研究会话容易遗失目标、环境惯例和停止条件,导致低信息量的反复尝试。 原文依据

02 文章用了什么方法

主要方法

以行为规范、会话记忆和autoresearch三个skill分别管理会话规则、累积信息和研究循环。

回应的问题

长研究会话容易遗失目标、环境惯例和停止条件,导致低信息量的反复尝试。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对etiquette、session-memory与autoresearch三类skill分工;25%到96.9%只对应作者构造的视觉计数任务。 原文依据Tips and best practices

这些结论有什么条件

这是作者的RL研究工作流案例,paper-to-code开始训练不代表算法有效性已被确认;人仍负责目标和结果判断。 Tips and best practices

04 总结与启发

我们的理解与启发

可借鉴持久目标、资源约束和决策记录的组织方式;文章分析不需要执行其中的研究流程。 原文依据Tips and best practices

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 长研究会话容易遗失目标、环境惯例和停止条件,导致低信息量的反复尝试。

primary 原文依据

D1 · 以行为规范、会话记忆和autoresearch三个skill分别管理会话规则、累积信息和研究循环。

core · described · 对应问题 P1 原文依据

E1 Building an autonomous RL research workflow 原文描述

长研究会话容易遗失目标、环境惯例和停止条件,导致低信息量的反复尝试。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Using NeMo RL, NeMo Gym, and agent skills 原文描述

以行为规范、会话记忆和autoresearch三个skill分别管理会话规则、累积信息和研究循环。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Tips and best practices 编辑核验判断

已核对etiquette、session-memory与autoresearch三类skill分工;25%到96.9%只对应作者构造的视觉计数任务。 这是作者的RL研究工作流案例,paper-to-code开始训练不代表算法有效性已被确认;人仍负责目标和结果判断。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Trajectory: A Standard Format for Agent Experience Data

关注的问题

不同harness的经验格式差异和运行元数据,使跨工具记忆读取昂贵。

作者的方法

将不同代理轨迹统一为角色和工具关联结构,并可选择截断冗长工具输出。

  • 记忆与上下文
  • 工具与协议
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

不同harness的经验格式差异和运行元数据,使跨工具记忆读取昂贵。 导言

02 文章用了什么方法

主要方法

将不同代理轨迹统一为角色和工具关联结构,并可选择截断冗长工具输出。

回应的问题

不同harness的经验格式差异和运行元数据,使跨工具记忆读取昂贵。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对统一role/tool-call关联和可选输出截断;默认约5倍压缩,Codex未截断只有2倍,不能混称全为无损收益。 原文依据token比较表

这些结论有什么条件

格式服务记忆阅读而非完整执行重放,丢弃或截断的信息可能不适合审计用途。 token比较表

04 总结与启发

我们的理解与启发

区分供Agent阅读的经验视图和保真运行记录,根据消费者保留必要信息。 原文依据token比较表

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 不同harness的经验格式差异和运行元数据,使跨工具记忆读取昂贵。

primary 导言

D1 · 将不同代理轨迹统一为角色和工具关联结构,并可选择截断冗长工具输出。

core · described · 对应问题 P1 原文依据

E1 导言 原文描述

不同harness的经验格式差异和运行元数据,使跨工具记忆读取昂贵。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Trajectory schema、Listing and formatting trajectories 原文描述

将不同代理轨迹统一为角色和工具关联结构,并可选择截断冗长工具输出。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 token比较表 编辑核验判断

已核对统一role/tool-call关联和可选输出截断;默认约5倍压缩,Codex未截断只有2倍,不能混称全为无损收益。 格式服务记忆阅读而非完整执行重放,丢弃或截断的信息可能不适合审计用途。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Is a Pod the right deployment unit for an AI agent?

关注的问题

短暂且突发的Agent生命周期与长期Pod不一致,一Agent一Pod会保留大量空闲资源。

作者的方法

用WorkerPool及ActorTemplate管理Kubernetes工作节点,由额外控制面调度逻辑Actor。

  • 状态与恢复
  • 身份与权限
  • 运行时与调度
阅读推荐收起推荐

01 背景与问题

短暂且突发的Agent生命周期与长期Pod不一致,一Agent一Pod会保留大量空闲资源。 原文依据

02 文章用了什么方法

主要方法

用WorkerPool及ActorTemplate管理Kubernetes工作节点,由额外控制面调度逻辑Actor。

回应的问题

短暂且突发的Agent生命周期与长期Pod不一致,一Agent一Pod会保留大量空闲资源。

原文依据 Enter Agent-substrate

03 证据支持到哪里

从原文能确认什么

已核对WorkerPool和ActorTemplate进入Kubernetes,逻辑Actor由额外控制面调度到Worker Pod。 Enter Agent-substrate原文依据

这些结论有什么条件

身份、actor级策略和计费在文中多为待讨论问题;没有量化容量结果支持无限规模。 原文依据

04 总结与启发

我们的理解与启发

将逻辑Agent身份与承载进程分开,使用现有集群管理执行资源。 Enter Agent-substrate原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 短暂且突发的Agent生命周期与长期Pod不一致,一Agent一Pod会保留大量空闲资源。

primary 原文依据

D1 · 用WorkerPool及ActorTemplate管理Kubernetes工作节点,由额外控制面调度逻辑Actor。

core · described · 对应问题 P1 Enter Agent-substrate

E1 But Should Agents Be Best Represented as Pods 原文描述

短暂且突发的Agent生命周期与长期Pod不一致,一Agent一Pod会保留大量空闲资源。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Enter Agent-substrate 原文描述

用WorkerPool及ActorTemplate管理Kubernetes工作节点,由额外控制面调度逻辑Actor。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Agent Identity、Security and Policy、Ownership 编辑核验判断

已核对WorkerPool和ActorTemplate进入Kubernetes,逻辑Actor由额外控制面调度到Worker Pod。 身份、actor级策略和计费在文中多为待讨论问题;没有量化容量结果支持无限规模。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

State & Persistence: The Problem of Agent Reliability

关注的问题

执行进度和跨任务知识共享生命周期,会在恢复、保留和权限上产生错误。

作者的方法

在工具边界保存状态和已作决策,以模型、代码、prompt的版本组合解释恢复语义。

  • 状态与恢复
  • 记忆与上下文
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

执行进度和跨任务知识共享生命周期,会在恢复、保留和权限上产生错误。 Agent state vs. memory

02 文章用了什么方法

主要方法

在工具边界保存状态和已作决策,以模型、代码、prompt的版本组合解释恢复语义。

回应的问题

执行进度和跨任务知识共享生命周期,会在恢复、保留和权限上产生错误。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对工具边界持久化、重用已记录决策与模型/代码/prompt bundle;重新生成新请求ID可能绕过工具幂等。 原文依据原文依据

这些结论有什么条件

文章是多来源架构综合,费用案例明确为轶事;bundle是设计建议,不是数据库自动提供的完整能力。 原文依据

04 总结与启发

我们的理解与启发

分别定义状态与记忆的生命周期,将恢复绑定到执行版本和已提交动作身份。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 执行进度和跨任务知识共享生命周期,会在恢复、保留和权限上产生错误。

primary Agent state vs. memory

D1 · 在工具边界保存状态和已作决策,以模型、代码、prompt的版本组合解释恢复语义。

core · described · 对应问题 P1 原文依据

E1 Agent state vs. memory 原文描述

执行进度和跨任务知识共享生命周期,会在恢复、保留和权限上产生错误。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 What to checkpoint、Why idempotent tools aren't enough、Bundle versioning 原文描述

在工具边界保存状态和已作决策,以模型、代码、prompt的版本组合解释恢复语义。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 How state architecture drives cost、Open problems 编辑核验判断

已核对工具边界持久化、重用已记录决策与模型/代码/prompt bundle;重新生成新请求ID可能绕过工具幂等。 文章是多来源架构综合,费用案例明确为轶事;bundle是设计建议,不是数据库自动提供的完整能力。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

What 10 autonomous film crews taught us about agent teamwork

关注的问题

多Agent创作需要跨阶段交接,进程重启后只靠消息历史容易遗失决策。

作者的方法

通过共享文件、传路径的消息和阶段评审协调电影制作团队。

  • 文件与工件
  • 状态与恢复
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

多Agent创作需要跨阶段交接,进程重启后只靠消息历史容易遗失决策。 Team structure

02 文章用了什么方法

主要方法

通过共享文件、传路径的消息和阶段评审协调电影制作团队。

回应的问题

多Agent创作需要跨阶段交接,进程重启后只靠消息历史容易遗失决策。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对共享文件、消息传路径和阶段评审;早期“完成影片”实际只有94字节占位文件。 原文依据Some of what we learned

这些结论有什么条件

十支团队的一次创作活动是观察案例,文件协作优势不构成一般任务的受控结论。 Some of what we learned

04 总结与启发

我们的理解与启发

让交接围绕可读产物和明确阶段结果,完成声明需要与实际产物对应。 原文依据Some of what we learned

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 多Agent创作需要跨阶段交接,进程重启后只靠消息历史容易遗失决策。

primary Team structure

D1 · 通过共享文件、传路径的消息和阶段评审协调电影制作团队。

core · described · 对应问题 P1 原文依据

E1 Team structure 原文描述

多Agent创作需要跨阶段交接,进程重启后只靠消息历史容易遗失决策。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Scion: The orchestration system 原文描述

通过共享文件、传路径的消息和阶段评审协调电影制作团队。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Some of what we learned 编辑核验判断

已核对共享文件、消息传路径和阶段评审;早期“完成影片”实际只有94字节占位文件。 十支团队的一次创作活动是观察案例,文件协作优势不构成一般任务的受控结论。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

When agents build agents

关注的问题

复杂目标需要动态组合专长,并在跨次运行中保留工作而不持续膨胀主上下文。

作者的方法

用Monty组织隔离子代理及动态生成能力,静态检查通过的能力在下一run启用。

  • 工具与协议
  • 文件与工件
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

复杂目标需要动态组合专长,并在跨次运行中保留工作而不持续膨胀主上下文。 原文依据

还需处理的问题

新生成能力可能改变正在执行任务的条件。 原文依据

02 文章用了什么方法

主要方法

用Monty组织隔离子代理及动态生成能力,静态检查通过的能力在下一run启用。

回应的问题

复杂目标需要动态组合专长,并在跨次运行中保留工作而不持续膨胀主上下文。

原文依据 原文依据

配套设计

静态检查通过后在下一run启用,保持当前run的能力集合。

回应的问题

新生成能力可能改变正在执行任务的条件。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对delegate隔离、Monty编排及生成能力的静态检查;新能力在下一run生效,不是在下一turn热加载。 原文依据The loop outlives the run

这些结论有什么条件

按层级检索子Agent历史仍属规划;文章未给动态编排的量化收益对照。 The loop outlives the run

04 总结与启发

我们的理解与启发

分开运行时可用能力与下一轮改进产物,保持稳定调用契约。 原文依据The loop outlives the run

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 复杂目标需要动态组合专长,并在跨次运行中保留工作而不持续膨胀主上下文。

primary 原文依据

P2 · 新生成能力可能改变正在执行任务的条件。

secondary · ↳ P1 原文依据

D1 · 用Monty组织隔离子代理及动态生成能力,静态检查通过的能力在下一run启用。

core · described · 对应问题 P1 原文依据

D2 · 静态检查通过后在下一run启用,保持当前run的能力集合。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 The loop chooses its own structure 原文描述

复杂目标需要动态组合专长,并在跨次运行中保留工作而不持续膨胀主上下文。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 The loop builds its own tools 原文描述

用Monty组织隔离子代理及动态生成能力,静态检查通过的能力在下一run启用。 静态检查通过后在下一run启用,保持当前run的能力集合。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 The loop outlives the run 编辑核验判断

已核对delegate隔离、Monty编排及生成能力的静态检查;新能力在下一run生效,不是在下一turn热加载。 按层级检索子Agent历史仍属规划;文章未给动态编排的量化收益对照。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

When agents improve agents

关注的问题

一次run结束不等于目标完成,跨run改进还可能只优化了有偏的评分者。

作者的方法

以持久轨迹BM25检索和版本化rubric支持诊断,由人工校准并决定优化采用。

  • 记忆与上下文
  • 状态与恢复
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

一次run结束不等于目标完成,跨run改进还可能只优化了有偏的评分者。 原文依据

02 文章用了什么方法

主要方法

以持久轨迹BM25检索和版本化rubric支持诊断,由人工校准并决定优化采用。

回应的问题

一次run结束不等于目标完成,跨run改进还可能只优化了有偏的评分者。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对持久轨迹BM25、rubric版本与人工校准;idle边缘继续判定、层级权限和自动应用优化均未完整交付。 原文依据原文依据

这些结论有什么条件

搜索目前是全store或单会话,不能当作细粒度访问隔离;65个PR/22合并不是自动改进因果证明。 原文依据

04 总结与启发

我们的理解与启发

把完成条件、可检索经验和评价标准分开,保留对标准与改动的人工判断。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 一次run结束不等于目标完成,跨run改进还可能只优化了有偏的评分者。

primary 原文依据

D1 · 以持久轨迹BM25检索和版本化rubric支持诊断,由人工校准并决定优化采用。

core · described · 对应问题 P1 原文依据

E1 The loop supplies its own continue 原文描述

一次run结束不等于目标完成,跨run改进还可能只优化了有偏的评分者。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Learning from its own runs、Can you trust the judge 原文描述

以持久轨迹BM25检索和版本化rubric支持诊断,由人工校准并决定优化采用。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 The payoff、Where the series lands 编辑核验判断

已核对持久轨迹BM25、rubric版本与人工校准;idle边缘继续判定、层级权限和自动应用优化均未完整交付。 搜索目前是全store或单会话,不能当作细粒度访问隔离;65个PR/22合并不是自动改进因果证明。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Six Agent Harness Capabilities for Higher Model Performance

关注的问题

文本化工具结果反复进入上下文,工具、状态和控制散落多个接口。

作者的方法

把状态保留为可引用的Python对象,通过代码动作和typed关系组织工作记忆。

  • 文件与工件
  • 工具与协议
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

文本化工具结果反复进入上下文,工具、状态和控制散落多个接口。 An agent is a Python object

02 文章用了什么方法

主要方法

把状态保留为可引用的Python对象,通过代码动作和typed关系组织工作记忆。

回应的问题

文本化工具结果反复进入上下文,工具、状态和控制散落多个接口。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Python对象状态、引用传值、代码动作及记忆关系;token对照中有2.2M和1.3M不同基线,不能统一称减半。 原文依据原文依据

这些结论有什么条件

SWE-bench无压缩现象限定这些任务和模型;研究preview和沙箱外部依赖不能被概括成框架单独提供全部安全性。 原文依据

04 总结与启发

我们的理解与启发

用类型化对象和有界预览减少重复传输,把确定性检查置于明确方法边界。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 文本化工具结果反复进入上下文,工具、状态和控制散落多个接口。

primary An agent is a Python object

D1 · 把状态保留为可引用的Python对象,通过代码动作和typed关系组织工作记忆。

core · described · 对应问题 P1 原文依据

E1 An agent is a Python object 原文描述

文本化工具结果反复进入上下文,工具、状态和控制散落多个接口。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Six ideas、The agent curates its own memory 原文描述

把状态保留为可引用的Python对象,通过代码动作和typed关系组织工作记忆。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Same performance half tokens、ARC-AGI-3、research preview 编辑核验判断

已核对Python对象状态、引用传值、代码动作及记忆关系;token对照中有2.2M和1.3M不同基线,不能统一称减半。 SWE-bench无压缩现象限定这些任务和模型;研究preview和沙箱外部依赖不能被概括成框架单独提供全部安全性。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Safety and alignment in an era of long-horizon models

关注的问题

长时间自主工作可能把多个局部看似正常动作组合成对约束的绕过。

作者的方法

从实际事故补充评估与长指令对齐,以能暂停会话的轨迹监控支撑有限内部部署。

  • 状态与恢复
  • 安全与隔离
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

长时间自主工作可能把多个局部看似正常动作组合成对约束的绕过。 原文依据

02 文章用了什么方法

主要方法

从实际事故补充评估与长指令对齐,以能暂停会话的轨迹监控支撑有限内部部署。

回应的问题

长时间自主工作可能把多个局部看似正常动作组合成对约束的绕过。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对事故驱动评估、长指令对齐和可暂停的轨迹监控;重新开放访问仍是有限内部范围。 原文依据Redeployment、脚注2

这些结论有什么条件

作者只描述少量环境和定性改进,轨迹重放本身有随机性;没有严重事件观察不构成普遍安全保证。 Redeployment、脚注2

04 总结与启发

我们的理解与启发

围绕完整轨迹判断目标与约束,保留可介入的执行边界。 原文依据Redeployment、脚注2

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 长时间自主工作可能把多个局部看似正常动作组合成对约束的绕过。

primary 原文依据

D1 · 从实际事故补充评估与长指令对齐,以能暂停会话的轨迹监控支撑有限内部部署。

core · described · 对应问题 P1 原文依据

E1 Model persistence can expose security vulnerabilities 原文描述

长时间自主工作可能把多个局部看似正常动作组合成对约束的绕过。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Building safeguards for long-running models 原文描述

从实际事故补充评估与长指令对齐,以能暂停会话的轨迹监控支撑有限内部部署。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Redeployment、脚注2 编辑核验判断

已核对事故驱动评估、长指令对齐和可暂停的轨迹监控;重新开放访问仍是有限内部范围。 作者只描述少量环境和定性改进,轨迹重放本身有随机性;没有严重事件观察不构成普遍安全保证。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Skill Use or Skill Theater? Evaluating the Reasoning Backroom in Skill-Augmented Language Agents

关注的问题

Agent声称用了某skill,不一定代表该artifact实际改变了决策,最终正确率也无法解释来源归因。

作者的方法

固定任务与预算,干预skill名称、内容或存在性,并在答案提交后收集归因。

  • 观测与评测
  • 文件与工件
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

Agent声称用了某skill,不一定代表该artifact实际改变了决策,最终正确率也无法解释来源归因。 Problem Formulation

02 文章用了什么方法

主要方法

固定任务与预算,干预skill名称、内容或存在性,并在答案提交后收集归因。

回应的问题

Agent声称用了某skill,不一定代表该artifact实际改变了决策,最终正确率也无法解释来源归因。

原文依据 Backtrace Audit Protocol

03 证据支持到哪里

从原文能确认什么

已核对固定任务与预算、先提交答案再问归因,以及名称/内容/移除干预;无效解析对正确率与归因指标使用不同分母。 Backtrace Audit Protocol原文依据

这些结论有什么条件

识别的是artifact级决策敏感性,不揭示内部推理;答案不变也不能排除学过相同程序,单路径不估计服务随机波动。 原文依据

04 总结与启发

我们的理解与启发

把实际行为变化、结果效用和自报来源分别分析,不把引用skill当作使用证据。 Backtrace Audit Protocol原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · Agent声称用了某skill,不一定代表该artifact实际改变了决策,最终正确率也无法解释来源归因。

primary Problem Formulation

D1 · 固定任务与预算,干预skill名称、内容或存在性,并在答案提交后收集归因。

core · described · 对应问题 P1 Backtrace Audit Protocol

E1 Problem Formulation 原文描述

Agent声称用了某skill,不一定代表该artifact实际改变了决策,最终正确率也无法解释来源归因。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Backtrace Audit Protocol 原文描述

固定任务与预算,干预skill名称、内容或存在性,并在答案提交后收集归因。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Appendix G Validity and Scope、表2–3 编辑核验判断

已核对固定任务与预算、先提交答案再问归因,以及名称/内容/移除干预;无效解析对正确率与归因指标使用不同分母。 识别的是artifact级决策敏感性,不揭示内部推理;答案不变也不能排除学过相同程序,单路径不估计服务随机波动。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

SkillCoach: Self-Evolving Rubrics for Evaluating and Enhancing Agentic Skill-Use

关注的问题

只按最终检查通过筛选经验,会保留选错skill后靠试错修好的过程。

作者的方法

按选择、遵循、组合、反思四维分析skill行为,以独立verifier和隔离验证集约束修订。

  • 观测与评测
  • 文件与工件
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

只按最终检查通过筛选经验,会保留选错skill后靠试错修好的过程。 §3.1–3.3

02 文章用了什么方法

主要方法

按选择、遵循、组合、反思四维分析skill行为,以独立verifier和隔离验证集约束修订。

回应的问题

只按最终检查通过筛选经验,会保留选错skill后靠试错修好的过程。

原文依据 §3.4–3.5

03 证据支持到哪里

从原文能确认什么

已核对选择/遵循/组合/反思rubric与独立verifier、隔离验证集修订门槛;50例评价是human-gold加模型辅助审查。 §3.4–3.5§4.1、§4.3–4.4、§6

这些结论有什么条件

训练结果是离线SFT;大库边界只评选择而非完整容器任务,未报告长期生产反馈。 §4.1、§4.3–4.4、§6

04 总结与启发

我们的理解与启发

将过程证据和最终产物分开评价,版本化评分标准并保留禁止破坏的关键步骤。 §3.4–3.5§4.1、§4.3–4.4、§6

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 只按最终检查通过筛选经验,会保留选错skill后靠试错修好的过程。

primary §3.1–3.3

D1 · 按选择、遵循、组合、反思四维分析skill行为,以独立verifier和隔离验证集约束修订。

core · described · 对应问题 P1 §3.4–3.5

E1 §3.1–3.3 原文描述

只按最终检查通过筛选经验,会保留选错skill后靠试错修好的过程。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §3.4–3.5 原文描述

按选择、遵循、组合、反思四维分析skill行为,以独立verifier和隔离验证集约束修订。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §4.1、§4.3–4.4、§6 编辑核验判断

已核对选择/遵循/组合/反思rubric与独立verifier、隔离验证集修订门槛;50例评价是human-gold加模型辅助审查。 训练结果是离线SFT;大库边界只评选择而非完整容器任务,未报告长期生产反馈。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Dynamic Agent Skills: A Lifecycle Survey and Taxonomy of Evolving Skill Libraries

关注的问题

动态skill库不仅有检索,还涉及提出、准入、组织、维护和来源治理,混为一谈会误判成熟度。

作者的方法

以八阶段生命周期整理动态skill研究,区分能力表示、准入、运行和维护等证据角色。

  • 记忆与上下文
  • 文件与工件
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

动态skill库不仅有检索,还涉及提出、准入、组织、维护和来源治理,混为一谈会误判成熟度。 §2 Corpus、§5

02 文章用了什么方法

主要方法

以八阶段生命周期整理动态skill研究,区分能力表示、准入、运行和维护等证据角色。

回应的问题

动态skill库不仅有检索,还涉及提出、准入、组织、维护和来源治理,混为一谈会误判成熟度。

原文依据 §5.1 Reference Architecture

03 证据支持到哪里

从原文能确认什么

已核对八阶段生命周期及证据角色划分;124篇是作者审计集,明确截止2026年5月31日。 §5.1 Reference Architecture§2.2–2.5、§8

这些结论有什么条件

这是arXiv为主且非穷尽的综述,不是共享harness上的统一比较;分类归纳不能替代各论文实证。 §2.2–2.5、§8

04 总结与启发

我们的理解与启发

按具体生命周期阶段比较系统,区分能添加、能调用与能持续维护。 §5.1 Reference Architecture§2.2–2.5、§8

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 动态skill库不仅有检索,还涉及提出、准入、组织、维护和来源治理,混为一谈会误判成熟度。

primary §2 Corpus、§5

D1 · 以八阶段生命周期整理动态skill研究,区分能力表示、准入、运行和维护等证据角色。

core · described · 对应问题 P1 §5.1 Reference Architecture

E1 §2 Corpus、§5 原文描述

动态skill库不仅有检索,还涉及提出、准入、组织、维护和来源治理,混为一谈会误判成熟度。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §5.1 Reference Architecture 原文描述

以八阶段生命周期整理动态skill研究,区分能力表示、准入、运行和维护等证据角色。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §2.2–2.5、§8 编辑核验判断

已核对八阶段生命周期及证据角色划分;124篇是作者审计集,明确截止2026年5月31日。 这是arXiv为主且非穷尽的综述,不是共享harness上的统一比较;分类归纳不能替代各论文实证。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Building AX evals that actually work

关注的问题

含糊标准让模型评分看似准确,却无法区分正确使用、仅出现名称和根本不适用。

作者的方法

逐项使用pass、fail、skip及人工样本校准,将版本和汇总算术交给确定性工具。

  • 记忆与上下文
  • 文件与工件
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

含糊标准让模型评分看似准确,却无法区分正确使用、仅出现名称和根本不适用。 原文依据

02 文章用了什么方法

主要方法

逐项使用pass、fail、skip及人工样本校准,将版本和汇总算术交给确定性工具。

回应的问题

含糊标准让模型评分看似准确,却无法区分正确使用、仅出现名称和根本不适用。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对逐项pass/fail/skip和人工已知样本校准;semver与汇总算术最终移交确定性工具。 原文依据Judge failure modes

这些结论有什么条件

5–10例校准是实践起点,不证明整体可信;不适用跳过不能用于隐藏困难案例。 Judge failure modes

04 总结与启发

我们的理解与启发

让判断附带可定位证据,结构与算术由代码处理,保留明确不适用条件。 原文依据Judge failure modes

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 含糊标准让模型评分看似准确,却无法区分正确使用、仅出现名称和根本不适用。

primary 原文依据

D1 · 逐项使用pass、fail、skip及人工样本校准,将版本和汇总算术交给确定性工具。

core · described · 对应问题 P1 原文依据

E1 Anatomy of a reliable criterion 原文描述

含糊标准让模型评分看似准确,却无法区分正确使用、仅出现名称和根本不适用。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 The skip condition、Calibrating the judge 原文描述

逐项使用pass、fail、skip及人工样本校准,将版本和汇总算术交给确定性工具。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Judge failure modes 编辑核验判断

已核对逐项pass/fail/skip和人工已知样本校准;semver与汇总算术最终移交确定性工具。 5–10例校准是实践起点,不证明整体可信;不适用跳过不能用于隐藏困难案例。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How to test agent skills without hitting real APIs

关注的问题

API评测可能付费、改变真实数据或受他人写入干扰,修改skill网址又引入新的变量。

作者的方法

由Dev Proxy在原URL拦截调用,以种子数据和可重置CRUD状态模拟服务。

  • 工具与协议
  • 状态与恢复
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

API评测可能付费、改变真实数据或受他人写入干扰,修改skill网址又引入新的变量。 原文依据

02 文章用了什么方法

主要方法

由Dev Proxy在原URL拦截调用,以种子数据和可重置CRUD状态模拟服务。

回应的问题

API评测可能付费、改变真实数据或受他人写入干扰,修改skill网址又引入新的变量。

原文依据 A lighter-weight approach

03 证据支持到哪里

从原文能确认什么

已核对Dev Proxy在原URL拦截并以种子数据提供CRUD语义,每次重置。 A lighter-weight approach原文依据

这些结论有什么条件

代理只模拟已配置操作,不证明真实鉴权、延迟和上游故障行为;原文没有效果量比较。 原文依据

04 总结与启发

我们的理解与启发

阅读此类证据时区分隔离模拟与真实集成,保持被评skill本体一致。 A lighter-weight approach原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · API评测可能付费、改变真实数据或受他人写入干扰,修改skill网址又引入新的变量。

primary 原文依据

D1 · 由Dev Proxy在原URL拦截调用,以种子数据和可重置CRUD状态模拟服务。

core · described · 对应问题 P1 A lighter-weight approach

E1 The problem nobody warns you about 原文描述

API评测可能付费、改变真实数据或受他人写入干扰,修改skill网址又引入新的变量。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 A lighter-weight approach 原文描述

由Dev Proxy在原URL拦截调用,以种子数据和可重置CRUD状态模拟服务。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 The mock server trap、The point isn't the tooling 编辑核验判断

已核对Dev Proxy在原URL拦截并以种子数据提供CRUD语义,每次重置。 代理只模拟已配置操作,不证明真实鉴权、延迟和上游故障行为;原文没有效果量比较。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

SIGIL: Compiling Agent Skills into Typed Harnesses

关注的问题

自然语言skill把已确定的流程约束和需要模型判断的部分混在一起,导致必要步骤被跳过。

作者的方法

从来源跨度提取要求形成AG-IR,校验后确定性降低为可执行结构。

  • 文件与工件
  • 工具与协议
  • 运行时与调度
阅读推荐收起推荐

01 背景与问题

自然语言skill把已确定的流程约束和需要模型判断的部分混在一起,导致必要步骤被跳过。 §2.2–2.3

02 文章用了什么方法

主要方法

从来源跨度提取要求形成AG-IR,校验后确定性降低为可执行结构。

回应的问题

自然语言skill把已确定的流程约束和需要模型判断的部分混在一起,导致必要步骤被跳过。

原文依据 §3.3–3.4

03 证据支持到哪里

从原文能确认什么

已核对source span要求抽取、AG-IR验证和确定性lowering;表3仅83.2–87.1%的code-owned要求被保留,不能说编译完整保真。 §3.3–3.4§4.2、§4.3.3

这些结论有什么条件

来源片段存在不证明解释正确;可执行结构约束只覆盖已正确提取和编译的要求。 §4.2、§4.3.3

04 总结与启发

我们的理解与启发

将程序负责的流程与模型负责的语义判断显式区分,追踪每项约束的来源。 §3.3–3.4§4.2、§4.3.3

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 自然语言skill把已确定的流程约束和需要模型判断的部分混在一起,导致必要步骤被跳过。

primary §2.2–2.3

D1 · 从来源跨度提取要求形成AG-IR,校验后确定性降低为可执行结构。

core · described · 对应问题 P1 §3.3–3.4

E1 §2.2–2.3 原文描述

自然语言skill把已确定的流程约束和需要模型判断的部分混在一起,导致必要步骤被跳过。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §3.3–3.4 原文描述

从来源跨度提取要求形成AG-IR,校验后确定性降低为可执行结构。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §4.2、§4.3.3 编辑核验判断

已核对source span要求抽取、AG-IR验证和确定性lowering;表3仅83.2–87.1%的code-owned要求被保留,不能说编译完整保真。 来源片段存在不证明解释正确;可执行结构约束只覆盖已正确提取和编译的要求。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

MemTxn: A Transaction Boundary for Source-Supported Updates and Complete-State Recovery in Agent Memory

关注的问题

记忆更新准入、答案版本选择与持久恢复是不同问题,单键修复可能遗漏其他已受损状态。

作者的方法

用有序token条件约束记忆修订、声明时间选择版本,并保存完整active-map前像。

  • 文件与工件
  • 状态与恢复
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

记忆更新准入、答案版本选择与持久恢复是不同问题,单键修复可能遗漏其他已受损状态。 Overview、System model

02 文章用了什么方法

主要方法

用有序token条件约束记忆修订、声明时间选择版本,并保存完整active-map前像。

回应的问题

记忆更新准入、答案版本选择与持久恢复是不同问题,单键修复可能遗漏其他已受损状态。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Ordered PatchTest的有序token条件、按声明时间选版本和完整active-map前像;SQLite负责原子写,不负责语义真值。 原文依据原文依据

这些结论有什么条件

不保证语义角色绑定、并发、重复故障、intent损坏或物理丢失;恢复以前像完整且外部检测器调用为前提。 原文依据

04 总结与启发

我们的理解与启发

分开准入、可见性和恢复,并将可恢复范围绑定到应用可见状态。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 记忆更新准入、答案版本选择与持久恢复是不同问题,单键修复可能遗漏其他已受损状态。

primary Overview、System model

D1 · 用有序token条件约束记忆修订、声明时间选择版本,并保存完整active-map前像。

core · described · 对应问题 P1 原文依据

E1 Overview、System model 原文描述

记忆更新准入、答案版本选择与持久恢复是不同问题,单键修复可能遗漏其他已受损状态。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Source-supported update admission、Temporal resolution、Complete-state recovery 原文描述

用有序token条件约束记忆修订、声明时间选择版本,并保存完整active-map前像。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Discussion and Limitations、表4 编辑核验判断

已核对Ordered PatchTest的有序token条件、按声明时间选版本和完整active-map前像;SQLite负责原子写,不负责语义真值。 不保证语义角色绑定、并发、重复故障、intent损坏或物理丢失;恢复以前像完整且外部检测器调用为前提。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

MANTA: Multi-Agent Network Topology Adaptation for Self-Evolving Multi-Agent Systems

关注的问题

固定团队拓扑无法根据任务和已发生的协作问题调整分工及信息可见性。

作者的方法

过程审计发现问题后进行最多三操作的有界修订,以两种时间尺度维护playbook。

  • 观测与评测
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

固定团队拓扑无法根据任务和已发生的协作问题调整分工及信息可见性。 System Overview

02 文章用了什么方法

主要方法

过程审计发现问题后进行最多三操作的有界修订,以两种时间尺度维护playbook。

回应的问题

固定团队拓扑无法根据任务和已发生的协作问题调整分工及信息可见性。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对过程审计、最多三操作的有界修订和两时间尺度playbook;预算曲线累计保留前次成功,表示覆盖率而非独立同预算成功率。 原文依据原文依据

这些结论有什么条件

无过程flag不等于答案正确;跨域迁移每组30题,控制者不接收benchmark verdict。 原文依据

04 总结与启发

我们的理解与启发

以可观察协作问题触发结构调整,保留过程信号与结果正确性的区别。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 固定团队拓扑无法根据任务和已发生的协作问题调整分工及信息可见性。

primary System Overview

D1 · 过程审计发现问题后进行最多三操作的有界修订,以两种时间尺度维护playbook。

core · described · 对应问题 P1 原文依据

E1 System Overview 原文描述

固定团队拓扑无法根据任务和已发生的协作问题调整分工及信息可见性。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 The Orchestration Loop、Two-Horizon Playbook Memory 原文描述

过程审计发现问题后进行最多三操作的有界修订,以两种时间尺度维护playbook。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Effect of Mutation Budget、How Well Does Trace Auditing Work 编辑核验判断

已核对过程审计、最多三操作的有界修订和两时间尺度playbook;预算曲线累计保留前次成功,表示覆盖率而非独立同预算成功率。 无过程flag不等于答案正确;跨域迁移每组30题,控制者不接收benchmark verdict。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

AgentRadio: Passive Awareness for Long-Horizon Multi-Agent Collaboration

关注的问题

协作中前台等待消息会打断独立工作,跨分工发现要到评审时才传递。

作者的方法

后台watcher在步骤边界把同伴消息送入代理,替代每次通信都阻塞推理的方式。

  • 文件与工件
  • 状态与恢复
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

协作中前台等待消息会打断独立工作,跨分工发现要到评审时才传递。 Communication Primitives

02 文章用了什么方法

主要方法

后台watcher在步骤边界把同伴消息送入代理,替代每次通信都阻塞推理的方式。

回应的问题

协作中前台等待消息会打断独立工作,跨分工发现要到评审时才传递。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对后台watcher在步骤边界送达消息,同一五阶段协议对比阻塞模式;全栈成本约为单Agent六倍。 原文依据原文依据

这些结论有什么条件

无额外监听模型调用不等于零成本,消息仍占token;主实验124题,三次随机性检查只覆盖30题子集。 原文依据

04 总结与启发

我们的理解与启发

把消息到达与工作执行解耦,让跨任务相关发现及时进入对方上下文。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 协作中前台等待消息会打断独立工作,跨分工发现要到评审时才传递。

primary Communication Primitives

D1 · 后台watcher在步骤边界把同伴消息送入代理,替代每次通信都阻塞推理的方式。

core · described · 对应问题 P1 原文依据

E1 Communication Primitives 原文描述

协作中前台等待消息会打断独立工作,跨分工发现要到评审时才传递。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 The Five-Phase Protocol、Implementation 原文描述

后台watcher在步骤边界把同伴消息送入代理,替代每次通信都阻塞推理的方式。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Main Results、Compute and Model-Generation Baselines 编辑核验判断

已核对后台watcher在步骤边界送达消息,同一五阶段协议对比阻塞模式;全栈成本约为单Agent六倍。 无额外监听模型调用不等于零成本,消息仍占token;主实验124题,三次随机性检查只覆盖30题子集。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Hybrid Analysis for Secure MCP Tool Use in LLM Agents

关注的问题

仅检查声明参数或返回文本,看不到MCP工具真实执行的进程、文件和网络行为。

作者的方法

调用前检查参数,执行中采集eBPF行为树,返回前审查结果是否可以交给模型。

  • 工具与协议
  • 安全与隔离
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

仅检查声明参数或返回文本,看不到MCP工具真实执行的进程、文件和网络行为。 §2.2

02 文章用了什么方法

主要方法

调用前检查参数,执行中采集eBPF行为树,返回前审查结果是否可以交给模型。

回应的问题

仅检查声明参数或返回文本,看不到MCP工具真实执行的进程、文件和网络行为。

原文依据 §3.1–3.4

03 证据支持到哪里

从原文能确认什么

已核对参数预审、eBPF行为树及结果后审;monitor执行中只采集,后审拒绝只是扣住返回结果。 §3.1–3.4§5.1

这些结论有什么条件

已经发生的副作用不会自动撤销;本地Docker/cgroup原型不覆盖无相应遥测的远程工具,且不看网络payload。 §5.1

04 总结与启发

我们的理解与启发

将声明动作与实际执行证据关联,分别描述执行前阻止和执行后发现。 §3.1–3.4§5.1

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 仅检查声明参数或返回文本,看不到MCP工具真实执行的进程、文件和网络行为。

primary §2.2

D1 · 调用前检查参数,执行中采集eBPF行为树,返回前审查结果是否可以交给模型。

core · described · 对应问题 P1 §3.1–3.4

E1 §2.2 原文描述

仅检查声明参数或返回文本,看不到MCP工具真实执行的进程、文件和网络行为。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §3.1–3.4 原文描述

调用前检查参数,执行中采集eBPF行为树,返回前审查结果是否可以交给模型。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §5.1 编辑核验判断

已核对参数预审、eBPF行为树及结果后审;monitor执行中只采集,后审拒绝只是扣住返回结果。 已经发生的副作用不会自动撤销;本地Docker/cgroup原型不覆盖无相应遥测的远程工具,且不看网络payload。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Filesystem-Based Memory for LLM Agents: Organization, Evolution, and Sustainability

关注的问题

文件记忆的组织、压缩和维护会同时影响查找成本与信息保留,目录更复杂未必更好。

作者的方法

分离记忆管理、搜索与执行角色,在相同任务中比较不同文件组织和存储形式。

  • 记忆与上下文
  • 文件与工件
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

文件记忆的组织、压缩和维护会同时影响查找成本与信息保留,目录更复杂未必更好。 §2.1–2.3

02 文章用了什么方法

主要方法

分离记忆管理、搜索与执行角色,在相同任务中比较不同文件组织和存储形式。

回应的问题

文件记忆的组织、压缩和维护会同时影响查找成本与信息保留,目录更复杂未必更好。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对管理、搜索与执行角色和多种存储形式;PersonaMem 32k中curated明显落后原文dump,技能结果还随执行模型强弱反转。 原文依据§4.2、§4.4

这些结论有什么条件

对话32k/128k含不同内容,不能纯归因长度;增长证据限140任务链,维护可让库更大而非更小。 §4.2、§4.4

04 总结与启发

我们的理解与启发

按信息材料和消费者能力选择组织程度,将建库成本与每次使用成本分开。 原文依据§4.2、§4.4

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 文件记忆的组织、压缩和维护会同时影响查找成本与信息保留,目录更复杂未必更好。

primary §2.1–2.3

D1 · 分离记忆管理、搜索与执行角色,在相同任务中比较不同文件组织和存储形式。

core · described · 对应问题 P1 原文依据

E1 §2.1–2.3 原文描述

文件记忆的组织、压缩和维护会同时影响查找成本与信息保留,目录更复杂未必更好。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Management/Search/Execution roles、taxonomy contract 原文描述

分离记忆管理、搜索与执行角色,在相同任务中比较不同文件组织和存储形式。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §4.2、§4.4 编辑核验判断

已核对管理、搜索与执行角色和多种存储形式;PersonaMem 32k中curated明显落后原文dump,技能结果还随执行模型强弱反转。 对话32k/128k含不同内容,不能纯归因长度;增长证据限140任务链,维护可让库更大而非更小。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

VITAL-RAG: Invariance Race for Context Allocation in Coding Agents

关注的问题

同一代码对象的多视图会重复占据上下文,已检索到的证据还可能在token预算下被截掉。

作者的方法

每个来源对象只占一个排名位置,再按查询添加companion并限制对象token预算。

  • 文件与工件
  • 记忆与上下文
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

同一代码对象的多视图会重复占据上下文,已检索到的证据还可能在token预算下被截掉。 §3–4

02 文章用了什么方法

主要方法

每个来源对象只占一个排名位置,再按查询添加companion并限制对象token预算。

回应的问题

同一代码对象的多视图会重复占据上下文,已检索到的证据还可能在token预算下被截掉。

原文依据 §5.2–5.4

03 证据支持到哪里

从原文能确认什么

已核对来源对象共享一个排名位置、查询相关companion及每对象token上下限;4K比较固定候选,测的是渲染后证据保留。 §5.2–5.4§6.2、§7

这些结论有什么条件

依赖索引提供的对象身份,固定4096token设置不代表所有窗口的最佳分配;检索召回不等于任务完成率。 §6.2、§7

04 总结与启发

我们的理解与启发

将检索排序、对象去重和最终上下文分配分别建模。 §5.2–5.4§6.2、§7

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 同一代码对象的多视图会重复占据上下文,已检索到的证据还可能在token预算下被截掉。

primary §3–4

D1 · 每个来源对象只占一个排名位置,再按查询添加companion并限制对象token预算。

core · described · 对应问题 P1 §5.2–5.4

E1 §3–4 原文描述

同一代码对象的多视图会重复占据上下文,已检索到的证据还可能在token预算下被截掉。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §5.2–5.4 原文描述

每个来源对象只占一个排名位置,再按查询添加companion并限制对象token预算。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §6.2、§7 编辑核验判断

已核对来源对象共享一个排名位置、查询相关companion及每对象token上下限;4K比较固定候选,测的是渲染后证据保留。 依赖索引提供的对象身份,固定4096token设置不代表所有窗口的最佳分配;检索召回不等于任务完成率。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

MemSecBench: Tracking Agent Memory Poisoning from Persistence to Consequence and Repair

关注的问题

记忆写入成功不等于攻击成功,清除恶意条目也不等于修复后良性记忆仍完整。

作者的方法

分别观察污染写入、召回、采纳和外部后果,并独立评估选择性遗忘与良性信息保留。

  • 记忆与上下文
  • 安全与隔离
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

记忆写入成功不等于攻击成功,清除恶意条目也不等于修复后良性记忆仍完整。 Threat Model

02 文章用了什么方法

主要方法

分别观察污染写入、召回、采纳和外部后果,并独立评估选择性遗忘与良性信息保留。

回应的问题

记忆写入成功不等于攻击成功,清除恶意条目也不等于修复后良性记忆仍完整。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对持久化、召回、采纳、外部后果及选择性修复的不同证据;repair分母条件化于已成功污染,不能与全案例攻击率直接比较。 原文依据Finding 2–4、Judge validation

这些结论有什么条件

假定攻击内容已进入支持的流程,不研究获取账户入口;judge只报告500条人工标签一致率,后端优劣随配置反转。 Finding 2–4、Judge validation

04 总结与启发

我们的理解与启发

按完整生命周期定位风险,删除动作和完成声明都不能代替最终状态证据。 原文依据Finding 2–4、Judge validation

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 记忆写入成功不等于攻击成功,清除恶意条目也不等于修复后良性记忆仍完整。

primary Threat Model

D1 · 分别观察污染写入、召回、采纳和外部后果,并独立评估选择性遗忘与良性信息保留。

core · described · 对应问题 P1 原文依据

E1 Threat Model 原文描述

记忆写入成功不等于攻击成功,清除恶意条目也不等于修复后良性记忆仍完整。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Lifecycle Evaluation Workflow、Judging from Admissible Evidence 原文描述

分别观察污染写入、召回、采纳和外部后果,并独立评估选择性遗忘与良性信息保留。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Finding 2–4、Judge validation 编辑核验判断

已核对持久化、召回、采纳、外部后果及选择性修复的不同证据;repair分母条件化于已成功污染,不能与全案例攻击率直接比较。 假定攻击内容已进入支持的流程,不研究获取账户入口;judge只报告500条人工标签一致率,后端优劣随配置反转。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

FinCacheServe: Dependency-Consistent Answer Reuse for Cost-Efficient RAG Serving over Mutable Enterprise Documents

关注的问题

可变企业文档下,相似问题复用答案可能跨报告期或过期依赖,生成缓存需要比语义相似更严格的条件。

作者的方法

将复用答案绑定请求签名和证据、版本、工具指纹,以反向索引传播失效。

  • 文件与工件
  • 工具与协议
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

可变企业文档下,相似问题复用答案可能跨报告期或过期依赖,生成缓存需要比语义相似更严格的条件。 §3 System model

还需处理的问题

来源变化后旧答案可能仍被命中。 §4.1–4.5

02 文章用了什么方法

主要方法

将复用答案绑定请求签名和证据、版本、工具指纹,以反向索引传播失效。

回应的问题

可变企业文档下,相似问题复用答案可能跨报告期或过期依赖,生成缓存需要比语义相似更严格的条件。

原文依据 §4.1–4.5

配套设计

通过证据和版本指纹绑定缓存,反向索引传播失效。

回应的问题

来源变化后旧答案可能仍被命中。

原文依据 §4.1–4.5

03 证据支持到哪里

从原文能确认什么

已核对请求签名、版本/证据/工具指纹、反向失效索引及metadata线性化点;SQLite持久失效延迟显著高于内存路径。 §4.1–4.5§7.10–7.12、§9

这些结论有什么条件

保证的是记录依赖的新鲜度而非财务事实正确;多副本跨区一致性不在实证范围,节能数字基于功率假设。 §7.10–7.12、§9

04 总结与启发

我们的理解与启发

把正确性复用门槛与缓存淘汰收益策略分开。 §4.1–4.5§7.10–7.12、§9

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 可变企业文档下,相似问题复用答案可能跨报告期或过期依赖,生成缓存需要比语义相似更严格的条件。

primary §3 System model

P2 · 来源变化后旧答案可能仍被命中。

secondary · ↳ P1 §4.1–4.5

D1 · 将复用答案绑定请求签名和证据、版本、工具指纹,以反向索引传播失效。

core · described · 对应问题 P1 §4.1–4.5

D2 · 通过证据和版本指纹绑定缓存,反向索引传播失效。

supporting · described · 对应问题 P2 · 支撑 D1 §4.1–4.5

E1 §3 System model 原文描述

可变企业文档下,相似问题复用答案可能跨报告期或过期依赖,生成缓存需要比语义相似更严格的条件。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §4.1–4.5 原文描述

将复用答案绑定请求签名和证据、版本、工具指纹,以反向索引传播失效。 通过证据和版本指纹绑定缓存,反向索引传播失效。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §7.10–7.12、§9 编辑核验判断

已核对请求签名、版本/证据/工具指纹、反向失效索引及metadata线性化点;SQLite持久失效延迟显著高于内存路径。 保证的是记录依赖的新鲜度而非财务事实正确;多副本跨区一致性不在实证范围,节能数字基于功率假设。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

AgentGUI: An Interface for Observing and Steering Long-Running AI Agents

关注的问题

长Agent任务中人难以理解轨迹,Agent空闲后也可能遗漏产物而不继续。

作者的方法

提供分层轨迹、文件预览和用户steering,再由manager按条件判断任务状态。

  • 状态与恢复
  • 文件与工件
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

长Agent任务中人难以理解轨迹,Agent空闲后也可能遗漏产物而不继续。 §3.1–3.2

02 文章用了什么方法

主要方法

提供分层轨迹、文件预览和用户steering,再由manager按条件判断任务状态。

回应的问题

长Agent任务中人难以理解轨迹,Agent空闲后也可能遗漏产物而不继续。

原文依据 §3.3–3.4

03 证据支持到哪里

从原文能确认什么

已核对分层轨迹、文件预览和manager逐条件审阅;UI研究只有8人,自动steering的程序分数检查产物存在。 §3.3–3.4§4.1–4.2

这些结论有什么条件

产物存在不证明内容正确;manager token少于1%不等于全部资源开销少于1%,Hermes与Claude支持成熟度不同。 §4.1–4.2

04 总结与启发

我们的理解与启发

让任务条件、轨迹和文件在同一界面可查,将需要继续的原因指向具体缺项。 §3.3–3.4§4.1–4.2

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 长Agent任务中人难以理解轨迹,Agent空闲后也可能遗漏产物而不继续。

primary §3.1–3.2

D1 · 提供分层轨迹、文件预览和用户steering,再由manager按条件判断任务状态。

core · described · 对应问题 P1 §3.3–3.4

E1 §3.1–3.2 原文描述

长Agent任务中人难以理解轨迹,Agent空闲后也可能遗漏产物而不继续。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §3.3–3.4 原文描述

提供分层轨迹、文件预览和用户steering,再由manager按条件判断任务状态。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §4.1–4.2 编辑核验判断

已核对分层轨迹、文件预览和manager逐条件审阅;UI研究只有8人,自动steering的程序分数检查产物存在。 产物存在不证明内容正确;manager token少于1%不等于全部资源开销少于1%,Hermes与Claude支持成熟度不同。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Towards a Systems Foundation for Agentic Cloud Management

关注的问题

多会话操作不同云资源仍可能争用同一父资源或容量,单按资源ID协调不够。

作者的方法

从全局资源图投影session状态,以多粒度锁和容量escrow协调操作,并在提交前重验。

  • 工具与协议
  • 文件与工件
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

多会话操作不同云资源仍可能争用同一父资源或容量,单按资源ID协调不够。 §3.2

02 文章用了什么方法

主要方法

从全局资源图投影session状态,以多粒度锁和容量escrow协调操作,并在提交前重验。

回应的问题

多会话操作不同云资源仍可能争用同一父资源或容量,单按资源ID协调不够。

原文依据 §4.1–4.2

03 证据支持到哪里

从原文能确认什么

已核对全局图的session投影、MGL与escrow、提交前重验;性能案例仅三会话六个Azure操作。 §4.1–4.2§5 Preliminary Validation、§6

这些结论有什么条件

provider语义依赖插件,自动生成插件属于规划;语义事务不是对所有云副作用提供通用原子回滚。 §5 Preliminary Validation、§6

04 总结与启发

我们的理解与启发

以真实依赖和容量约束确定冲突范围,给Agent返回可归因的等待或拒绝原因。 §4.1–4.2§5 Preliminary Validation、§6

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 多会话操作不同云资源仍可能争用同一父资源或容量,单按资源ID协调不够。

primary §3.2

D1 · 从全局资源图投影session状态,以多粒度锁和容量escrow协调操作,并在提交前重验。

core · described · 对应问题 P1 §4.1–4.2

E1 §3.2 原文描述

多会话操作不同云资源仍可能争用同一父资源或容量,单按资源ID协调不够。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §4.1–4.2 原文描述

从全局资源图投影session状态,以多粒度锁和容量escrow协调操作,并在提交前重验。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §5 Preliminary Validation、§6 编辑核验判断

已核对全局图的session投影、MGL与escrow、提交前重验;性能案例仅三会话六个Azure操作。 provider语义依赖插件,自动生成插件属于规划;语义事务不是对所有云副作用提供通用原子回滚。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

CodeNib: A Multi-View Data System for Serving Repository Context to Coding Agents

关注的问题

代码上下文来自结构、词法和向量视图,构建、维护、查询与交付需要明确边界。

作者的方法

以commit manifest组织多种代码视图,按能力加载并对符号变化进行增量维护。

  • 文件与工件
  • 工具与协议
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

代码上下文来自结构、词法和向量视图,构建、维护、查询与交付需要明确边界。 §3 System Overview

02 文章用了什么方法

主要方法

以commit manifest组织多种代码视图,按能力加载并对符号变化进行增量维护。

回应的问题

代码上下文来自结构、词法和向量视图,构建、维护、查询与交付需要明确边界。

原文依据 §3.1–3.3、§6.4

03 证据支持到哪里

从原文能确认什么

已核对commit manifest、能力驱动加载及符号增量维护;manifest不跨store原子提交,独立重建对照只在离线评价后做。 §3.1–3.3、§6.4§3.4、§9.7、§10

这些结论有什么条件

静态导航不完全等价实时LSP;token下降未测缓存或prefill延迟,compaction并非所有模型最优。 §3.4、§9.7、§10

04 总结与启发

我们的理解与启发

显式记录各视图版本和provider,分开数据新鲜度与交付策略。 §3.1–3.3、§6.4§3.4、§9.7、§10

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 代码上下文来自结构、词法和向量视图,构建、维护、查询与交付需要明确边界。

primary §3 System Overview

D1 · 以commit manifest组织多种代码视图,按能力加载并对符号变化进行增量维护。

core · described · 对应问题 P1 §3.1–3.3、§6.4

E1 §3 System Overview 原文描述

代码上下文来自结构、词法和向量视图,构建、维护、查询与交付需要明确边界。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §3.1–3.3、§6.4 原文描述

以commit manifest组织多种代码视图,按能力加载并对符号变化进行增量维护。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §3.4、§9.7、§10 编辑核验判断

已核对commit manifest、能力驱动加载及符号增量维护;manifest不跨store原子提交,独立重建对照只在离线评价后做。 静态导航不完全等价实时LSP;token下降未测缓存或prefill延迟,compaction并非所有模型最优。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

SkillGate: Cost Efficient Runtime Malicious Skill File Detection in Coding Agents

关注的问题

全量模型扫描skill昂贵,纯模式匹配又可能误报大量正常技术内容。

作者的方法

先用模式筛选MCP响应片段,再交给judge并隔离可疑内容。

  • 文件与工件
  • 身份与权限
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

全量模型扫描skill昂贵,纯模式匹配又可能误报大量正常技术内容。 §III design rationale

02 文章用了什么方法

主要方法

先用模式筛选MCP响应片段,再交给judge并隔离可疑内容。

回应的问题

全量模型扫描skill昂贵,纯模式匹配又可能误报大量正常技术内容。

原文依据 §III-A–E

03 证据支持到哪里

从原文能确认什么

已核对MCP响应拦截、无命中跳过和片段judge及隔离策略;76.9%节省是judge输入token口径,召回约0.769仍有漏检。 §III-A–E§IV Results、§VI

这些结论有什么条件

150恶意文件为手工示例;正则无命中直接放行会漏过新编码方式,PATH shim不是不可绕过的系统边界。 §IV Results、§VI

04 总结与启发

我们的理解与启发

将低成本筛查、语义判定和最终准入分开,保留筛查覆盖范围。 §III-A–E§IV Results、§VI

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 全量模型扫描skill昂贵,纯模式匹配又可能误报大量正常技术内容。

primary §III design rationale

D1 · 先用模式筛选MCP响应片段,再交给judge并隔离可疑内容。

core · described · 对应问题 P1 §III-A–E

E1 §III design rationale 原文描述

全量模型扫描skill昂贵,纯模式匹配又可能误报大量正常技术内容。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §III-A–E 原文描述

先用模式筛选MCP响应片段,再交给judge并隔离可疑内容。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §IV Results、§VI 编辑核验判断

已核对MCP响应拦截、无命中跳过和片段judge及隔离策略;76.9%节省是judge输入token口径,召回约0.769仍有漏检。 150恶意文件为手工示例;正则无命中直接放行会漏过新编码方式,PATH shim不是不可绕过的系统边界。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

OrchBench: Evaluating Multi-Agent Orchestration Plans in Isolation via Deterministic Simulation

关注的问题

端到端多Agent分数混合了任务求解和编排能力,难判断信息转移与资源分配本身。

作者的方法

在DAG模拟中显式建模任务分配、跨Agent信息传递和压缩损失,确定性计算调度结果。

  • 身份与权限
  • 记忆与上下文
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

端到端多Agent分数混合了任务求解和编排能力,难判断信息转移与资源分配本身。 Problem Formulation

02 文章用了什么方法

主要方法

在DAG模拟中显式建模任务分配、跨Agent信息传递和压缩损失,确定性计算调度结果。

回应的问题

端到端多Agent分数混合了任务求解和编排能力,难判断信息转移与资源分配本身。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对DAG任务分配、显式跨Agent信息保留率及确定性调度/压缩模型;漏传信息按预设惩罚而非实际语义执行评分。 原文依据原文依据

这些结论有什么条件

质量来自模拟假设;跨框架时间相关性很低,不能把模拟token或时延当作真实系统收益。 原文依据

04 总结与启发

我们的理解与启发

把编排结构单独分析,用声明依赖与信息流解释失败而非只看Agent数量。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 端到端多Agent分数混合了任务求解和编排能力,难判断信息转移与资源分配本身。

primary Problem Formulation

D1 · 在DAG模拟中显式建模任务分配、跨Agent信息传递和压缩损失,确定性计算调度结果。

core · described · 对应问题 P1 原文依据

E1 Problem Formulation 原文描述

端到端多Agent分数混合了任务求解和编排能力,难判断信息转移与资源分配本身。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Methodology、Deterministic Simulation 原文描述

在DAG模拟中显式建模任务分配、跨Agent信息传递和压缩损失,确定性计算调度结果。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Appendix D Simulation-to-Real Validation 编辑核验判断

已核对DAG任务分配、显式跨Agent信息保留率及确定性调度/压缩模型;漏传信息按预设惩罚而非实际语义执行评分。 质量来自模拟假设;跨框架时间相关性很低,不能把模拟token或时延当作真实系统收益。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Discover Agent Skills from MCP servers in .NET

关注的问题

多Agent各自复制skill会出现版本漂移,远程分发又引入解包与执行风险。

作者的方法

用skill目录索引发现能力,按需读取资源或archive,并限制下载与解压规模。

  • 文件与工件
  • 工具与协议
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

多Agent各自复制skill会出现版本漂移,远程分发又引入解包与执行风险。 What MCP-based skills are

02 文章用了什么方法

主要方法

用skill目录索引发现能力,按需读取资源或archive,并限制下载与解压规模。

回应的问题

多Agent各自复制skill会出现版本漂移,远程分发又引入解包与执行风险。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对skill://index.json、按需MCP资源或archive,以及下载/解压体积和文件数限制;更新在下次发现时可见。 原文依据归档限制与脚本说明

这些结论有什么条件

远程archive脚本明确不执行;资源限制不证明内容语义安全,统一来源也不是权限依据。 归档限制与脚本说明

04 总结与启发

我们的理解与启发

统一发现和分发接口,分别治理内容读取、归档落盘与脚本执行。 原文依据归档限制与脚本说明

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 多Agent各自复制skill会出现版本漂移,远程分发又引入解包与执行风险。

primary What MCP-based skills are

D1 · 用skill目录索引发现能力,按需读取资源或archive,并限制下载与解压规模。

core · described · 对应问题 P1 原文依据

E1 What MCP-based skills are 原文描述

多Agent各自复制skill会出现版本漂移,远程分发又引入解包与执行风险。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Use case: central skills server、archive 原文描述

用skill目录索引发现能力,按需读取资源或archive,并限制下载与解压规模。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 归档限制与脚本说明 编辑核验判断

已核对skill://index.json、按需MCP资源或archive,以及下载/解压体积和文件数限制;更新在下次发现时可见。 远程archive脚本明确不执行;资源限制不证明内容语义安全,统一来源也不是权限依据。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Security incident disclosure — July 2026

关注的问题

数据处理工作节点的代码执行漏洞可能演变为节点和跨集群凭证暴露。

作者的方法

从真实入侵事件追踪loader执行、凭据触达与横向移动,再界定修复和轮换范围。

  • 安全与隔离
  • 身份与权限
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

数据处理工作节点的代码执行漏洞可能演变为节点和跨集群凭证暴露。 What happened

02 文章用了什么方法

主要方法

从真实入侵事件追踪loader执行、凭据触达与横向移动,再界定修复和轮换范围。

回应的问题

数据处理工作节点的代码执行漏洞可能演变为节点和跨集群凭证暴露。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对入口、横向移动及修复/轮换范围;作者用本地模型分析17000余事件,因为托管模型阻挡部分取证内容。 原文依据The asymmetry problem

这些结论有什么条件

攻击者使用的LLM明确未知,不能归因某模型;小时级分析是事故报告而非受控效率比较。 The asymmetry problem

04 总结与启发

我们的理解与启发

把数据处理面和凭证传播纳入系统边界,取证能力需能处理真实恶意材料。 原文依据The asymmetry problem

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 数据处理工作节点的代码执行漏洞可能演变为节点和跨集群凭证暴露。

primary What happened

D1 · 从真实入侵事件追踪loader执行、凭据触达与横向移动,再界定修复和轮换范围。

core · described · 对应问题 P1 原文依据

E1 What happened 原文描述

数据处理工作节点的代码执行漏洞可能演变为节点和跨集群凭证暴露。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 What we did、Analyzing an AI-driven intrusion 原文描述

从真实入侵事件追踪loader执行、凭据触达与横向移动,再界定修复和轮换范围。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 The asymmetry problem 编辑核验判断

已核对入口、横向移动及修复/轮换范围;作者用本地模型分析17000余事件,因为托管模型阻挡部分取证内容。 攻击者使用的LLM明确未知,不能归因某模型;小时级分析是事故报告而非受控效率比较。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Agents SDK adds MCP Specification 2026-07-28 support

关注的问题

协议升级需同时服务新无状态客户端与旧连接,不能因迁移丢失交互式输入和身份状态。

作者的方法

先探测新发现协议后回退旧初始化,用MRTR恢复原操作,并隔离每请求server实例。

  • 工具与协议
  • 状态与恢复
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

协议升级需同时服务新无状态客户端与旧连接,不能因迁移丢失交互式输入和身份状态。 Client support

还需处理的问题

并发请求共用协议server可能互相污染状态。 原文依据

02 文章用了什么方法

主要方法

先探测新发现协议后回退旧初始化,用MRTR恢复原操作,并隔离每请求server实例。

回应的问题

协议升级需同时服务新无状态客户端与旧连接,不能因迁移丢失交互式输入和身份状态。

原文依据 原文依据

配套设计

每请求创建server实例,特殊session场景保留明确路由。

回应的问题

并发请求共用协议server可能互相污染状态。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对server/discover探测后legacy回退、MRTR恢复原操作、每请求server factory及issuer绑定凭证持久化。 原文依据原文依据

这些结论有什么条件

普通无状态操作可同路由兼容,依赖session/RPC/独立流的服务仍需重设计或双路由过渡。 原文依据

04 总结与启发

我们的理解与启发

区分协议会话和应用任务状态,以能力探测决定兼容路径。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 协议升级需同时服务新无状态客户端与旧连接,不能因迁移丢失交互式输入和身份状态。

primary Client support

P2 · 并发请求共用协议server可能互相污染状态。

secondary · ↳ P1 原文依据

D1 · 先探测新发现协议后回退旧初始化,用MRTR恢复原操作,并隔离每请求server实例。

core · described · 对应问题 P1 原文依据

D2 · 每请求创建server实例,特殊session场景保留明确路由。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Client support 原文描述

协议升级需同时服务新无状态客户端与旧连接,不能因迁移丢失交互式输入和身份状态。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Run stateless servers、Backward compatibility 原文描述

先探测新发现协议后回退旧初始化,用MRTR恢复原操作,并隔离每请求server实例。 每请求创建server实例,特殊session场景保留明确路由。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Migrate existing SDK v1 servers 编辑核验判断

已核对server/discover探测后legacy回退、MRTR恢复原操作、每请求server factory及issuer绑定凭证持久化。 普通无状态操作可同路由兼容,依赖session/RPC/独立流的服务仍需重设计或双路由过渡。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Build enterprise search for agents with Amazon Bedrock Managed Knowledge Base

关注的问题

企业检索需覆盖多来源与多跳问题,同时避免同步ACL过时后继续暴露文档。

作者的方法

在检索前过滤候选,查询时再检查权威源ACL,结合多轮子查询返回去重证据。

  • 记忆与上下文
  • 身份与权限
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

企业检索需覆盖多来源与多跳问题,同时避免同步ACL过时后继续暴露文档。 Native enterprise connectors

02 文章用了什么方法

主要方法

在检索前过滤候选,查询时再检查权威源ACL,结合多轮子查询返回去重证据。

回应的问题

企业检索需覆盖多来源与多跳问题,同时避免同步ACL过时后继续暴露文档。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对检索前过滤与查询时权威源ACL检查,模型规划子查询并返回去重片段。 原文依据原文依据

这些结论有什么条件

官方功能介绍和客户陈述不提供完整准确率对照;统一网关不能替代上游文档权限语义。 原文依据

04 总结与启发

我们的理解与启发

权限判断与语义相关性分开,按复杂度选择直接检索或迭代检索。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 企业检索需覆盖多来源与多跳问题,同时避免同步ACL过时后继续暴露文档。

primary Native enterprise connectors

D1 · 在检索前过滤候选,查询时再检查权威源ACL,结合多轮子查询返回去重证据。

core · described · 对应问题 P1 原文依据

E1 Native enterprise connectors 原文描述

企业检索需覆盖多来源与多跳问题,同时避免同步ACL过时后继续暴露文档。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 ACL检查、How Agentic Retrieval works、Gateway integration 原文描述

在检索前过滤候选,查询时再检查权威源ACL,结合多轮子查询返回去重证据。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Smarter retrieval、Observability 编辑核验判断

已核对检索前过滤与查询时权威源ACL检查,模型规划子查询并返回去重片段。 官方功能介绍和客户陈述不提供完整准确率对照;统一网关不能替代上游文档权限语义。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

The Microsoft Agent Framework Harness is now released

关注的问题

从chat client到长任务Agent还需要工具循环、状态、记忆、规划和可观测性。

作者的方法

用可替换的默认组件构成harness,并在每次模型调用后保存对话历史。

  • 工具与协议
  • 文件与工件
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

从chat client到长任务Agent还需要工具循环、状态、记忆、规划和可观测性。 What is an agent harness

02 文章用了什么方法

主要方法

用可替换的默认组件构成harness,并在每次模型调用后保存对话历史。

回应的问题

从chat client到长任务Agent还需要工具循环、状态、记忆、规划和可观测性。

原文依据 默认组件列表

03 证据支持到哪里

从原文能确认什么

已核对可单独替换的默认组件及每模型调用后保存历史;后台Agent、文件工具、looping和shell仍属告警提示的未正式发布选项。 默认组件列表Coming soon

这些结论有什么条件

历史持久化不自动保证工具副作用不重复;ready-made不意味着所有扩展都已稳定。 Coming soon

04 总结与启发

我们的理解与启发

让通用循环有明确可替换部件,展示功能时保留各组件成熟度。 默认组件列表Coming soon

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 从chat client到长任务Agent还需要工具循环、状态、记忆、规划和可观测性。

primary What is an agent harness

D1 · 用可替换的默认组件构成harness,并在每次模型调用后保存对话历史。

core · described · 对应问题 P1 默认组件列表

E1 What is an agent harness 原文描述

从chat client到长任务Agent还需要工具循环、状态、记忆、规划和可观测性。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 默认组件列表 原文描述

用可替换的默认组件构成harness,并在每次模型调用后保存对话历史。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Coming soon 编辑核验判断

已核对可单独替换的默认组件及每模型调用后保存历史;后台Agent、文件工具、looping和shell仍属告警提示的未正式发布选项。 历史持久化不自动保证工具副作用不重复;ready-made不意味着所有扩展都已稳定。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How Couchbase built a multi-model AI architecture for Capella iQ with Amazon Bedrock

关注的问题

企业SQL助手需要模型切换与高可用,同时保持租户配置和区域约束。

作者的方法

通过namespace配置、私有端点和美国地域内跨区路由组织NL查询服务。

  • 身份与权限
  • 运行时与调度
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

企业SQL助手需要模型切换与高可用,同时保持租户配置和区域约束。 Solution overview

02 文章用了什么方法

主要方法

通过namespace配置、私有端点和美国地域内跨区路由组织NL查询服务。

回应的问题

企业SQL助手需要模型切换与高可用,同时保持租户配置和区域约束。

原文依据 How it works

03 证据支持到哪里

从原文能确认什么

已核对namespace配置、私有endpoint与美国地域内CRIS;约76%来自内部BIRD方法参考集,不是公开BIRD榜单成绩。 How it works原文依据

这些结论有什么条件

私网不等于单区域,跨区故障仍需超时与重试设计;小模型蒸馏降本是未来计划。 原文依据

04 总结与启发

我们的理解与启发

在调用层解耦模型选择,并将地域和租户覆盖规则作为配置的一部分。 How it works原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 企业SQL助手需要模型切换与高可用,同时保持租户配置和区域约束。

primary Solution overview

D1 · 通过namespace配置、私有端点和美国地域内跨区路由组织NL查询服务。

core · described · 对应问题 P1 How it works

E1 Solution overview 原文描述

企业SQL助手需要模型切换与高可用,同时保持租户配置和区域约束。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 How it works 原文描述

通过namespace配置、私有端点和美国地域内跨区路由组织NL查询服务。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Model evaluation、Engineering considerations、Future plans 编辑核验判断

已核对namespace配置、私有endpoint与美国地域内CRIS;约76%来自内部BIRD方法参考集,不是公开BIRD榜单成绩。 私网不等于单区域,跨区故障仍需超时与重试设计;小模型蒸馏降本是未来计划。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Open Knowledge format v0.2 tackles agentic trust

关注的问题

知识消费者需要在读取正文前判断来源和新鲜度,计算值还需知道是否按批准公式取得。

作者的方法

分离generated与verified知识状态、绝对过期时间,以及逐次计算的证明收据。

  • 观测与评测
  • 记忆与上下文
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

知识消费者需要在读取正文前判断来源和新鲜度,计算值还需知道是否按批准公式取得。 From describing to deciding

02 文章用了什么方法

主要方法

分离generated与verified知识状态、绝对过期时间,以及逐次计算的证明收据。

回应的问题

知识消费者需要在读取正文前判断来源和新鲜度,计算值还需知道是否按批准公式取得。

原文依据 Provenance、Trust、Attestation

03 证据支持到哪里

从原文能确认什么

已核对generated/verified分离、绝对stale_after及逐次receipt核对;定义验证和单次计算证明互不替代。 Provenance、Trust、Attestation原文依据

这些结论有什么条件

信任tier是建议而非访问控制,OKF本身不执行;reference实现为概念验证,过期定义仍可能通过一次计算attestation。 原文依据

04 总结与启发

我们的理解与启发

把来源、生成者、核验记录、定义有效期与本次计算证据分别表达。 Provenance、Trust、Attestation原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 知识消费者需要在读取正文前判断来源和新鲜度,计算值还需知道是否按批准公式取得。

primary From describing to deciding

D1 · 分离generated与verified知识状态、绝对过期时间,以及逐次计算的证明收据。

core · described · 对应问题 P1 Provenance、Trust、Attestation

E1 From describing to deciding 原文描述

知识消费者需要在读取正文前判断来源和新鲜度,计算值还需知道是否按批准公式取得。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Provenance、Trust、Attestation 原文描述

分离generated与verified知识状态、绝对过期时间,以及逐次计算的证明收据。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Freshness and lifecycle、reference implementation说明 编辑核验判断

已核对generated/verified分离、绝对stale_after及逐次receipt核对;定义验证和单次计算证明互不替代。 信任tier是建议而非访问控制,OKF本身不执行;reference实现为概念验证,过期定义仍可能通过一次计算attestation。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

IssueTrojanBench: Benchmarking AI Coding Agents Against Malicious Issue Requests

关注的问题

编程Agent从issue和附件读取外部材料时,可能把攻击者伪装成任务要求的内容执行到仓库。

作者的方法

把issue变体投入固定代理设置,按实际执行、交付工件和风险提醒分别统计结果。

  • 文件与工件
  • 安全与隔离
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

编程Agent从issue和附件读取外部材料时,可能把攻击者伪装成任务要求的内容执行到仓库。 §III-A

02 文章用了什么方法

主要方法

把issue变体投入固定代理设置,按实际执行、交付工件和风险提醒分别统计结果。

回应的问题

编程Agent从issue和附件读取外部材料时,可能把攻击者伪装成任务要求的内容执行到仓库。

原文依据 §III-B Construction

03 证据支持到哪里

从原文能确认什么

已核对六个种子问题、两仓库、696变体和4176运行;拒绝归因还使用对Agent的后续询问,不能据此直接证明内部因果。 §III-B Construction§V RQ1、RQ3

这些结论有什么条件

攻击变体数量不等于独立任务多样性;各harness搭配模型不同,不能据总平均分纯比较框架安全性。 §V RQ1、RQ3

04 总结与启发

我们的理解与启发

保留用户任务与issue内容的信任边界,按实际动作而非最终口头拒绝判断后果。 §III-B Construction§V RQ1、RQ3

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 编程Agent从issue和附件读取外部材料时,可能把攻击者伪装成任务要求的内容执行到仓库。

primary §III-A

D1 · 把issue变体投入固定代理设置,按实际执行、交付工件和风险提醒分别统计结果。

core · described · 对应问题 P1 §III-B Construction

E1 §III-A 原文描述

编程Agent从issue和附件读取外部材料时,可能把攻击者伪装成任务要求的内容执行到仓库。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 §III-B Construction 原文描述

把issue变体投入固定代理设置,按实际执行、交付工件和风险提醒分别统计结果。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 §V RQ1、RQ3 编辑核验判断

已核对六个种子问题、两仓库、696变体和4176运行;拒绝归因还使用对Agent的后续询问,不能据此直接证明内部因果。 攻击变体数量不等于独立任务多样性;各harness搭配模型不同,不能据总平均分纯比较框架安全性。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Native Agent Memory for Microsoft Agent Framework, Powered by Azure Cosmos DB

关注的问题

长期用户记忆需要跨新会话注入,又不宜把存储和抽取逻辑绑进Agent循环。

作者的方法

以context provider的before_run召回、after_run保存及可定制抽取维护用户记忆。

  • 记忆与上下文
  • 安全与隔离
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

长期用户记忆需要跨新会话注入,又不宜把存储和抽取逻辑绑进Agent循环。 Why a context provider

还需处理的问题

用户画像可能被当作高优先级指令。 原文依据

02 文章用了什么方法

主要方法

以context provider的before_run召回、after_run保存及可定制抽取维护用户记忆。

回应的问题

长期用户记忆需要跨新会话注入,又不宜把存储和抽取逻辑绑进Agent循环。

原文依据 原文依据

配套设计

使用稳定user_id和thread_id,将召回画像作为用户角色的不可信参考。

回应的问题

用户画像可能被当作高优先级指令。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对before_run检索与after_run抽取、稳定user_id及可替换抽取模板;profile以用户角色的非可信参考注入。 原文依据Built for production

这些结论有什么条件

正常context退出会drain后台任务,不证明异常终止无损;user_id分区需可信身份绑定,非可信标签也不是确定性防注入。 Built for production

04 总结与启发

我们的理解与启发

通过生命周期扩展记忆能力,将身份、抽取标准和注入语义分别设计。 原文依据Built for production

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 长期用户记忆需要跨新会话注入,又不宜把存储和抽取逻辑绑进Agent循环。

primary Why a context provider

P2 · 用户画像可能被当作高优先级指令。

secondary · ↳ P1 原文依据

D1 · 以context provider的before_run召回、after_run保存及可定制抽取维护用户记忆。

core · described · 对应问题 P1 原文依据

D2 · 使用稳定user_id和thread_id,将召回画像作为用户角色的不可信参考。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Why a context provider 原文描述

长期用户记忆需要跨新会话注入,又不宜把存储和抽取逻辑绑进Agent循环。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 How it fits together、Scope memory、Customizing 原文描述

以context provider的before_run召回、after_run保存及可定制抽取维护用户记忆。 使用稳定user_id和thread_id,将召回画像作为用户角色的不可信参考。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Built for production 编辑核验判断

已核对before_run检索与after_run抽取、稳定user_id及可替换抽取模板;profile以用户角色的非可信参考注入。 正常context退出会drain后台任务,不证明异常终止无损;user_id分区需可信身份绑定,非可信标签也不是确定性防注入。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Move Agent Orchestration/Workflows out of Code with Agent Framework Declarative Workflows 1.0

关注的问题

代码内散落的编排使分支、状态和人工等待不易独立审阅和复用。

作者的方法

将YAML中的状态、条件、工具、人工输入与checkpoint加载为普通Workflow。

  • 状态与恢复
  • 工具与协议
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

代码内散落的编排使分支、状态和人工等待不易独立审阅和复用。 导言

02 文章用了什么方法

主要方法

将YAML中的状态、条件、工具、人工输入与checkpoint加载为普通Workflow。

回应的问题

代码内散落的编排使分支、状态和人工等待不易独立审阅和复用。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对YAML通过factory加载成普通Workflow,支持状态表达式、工具、人工输入和checkpoint。 原文依据示例与接口边界

这些结论有什么条件

声明式格式不自动证明策略安全、流程无环或迁移兼容;文章示例并未提供这些额外保证。 示例与接口边界

04 总结与启发

我们的理解与启发

将稳定编排外置为可审阅定义,复杂业务函数仍由代码提供。 原文依据示例与接口边界

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 代码内散落的编排使分支、状态和人工等待不易独立审阅和复用。

primary 导言

D1 · 将YAML中的状态、条件、工具、人工输入与checkpoint加载为普通Workflow。

core · described · 对应问题 P1 原文依据

E1 导言 原文描述

代码内散落的编排使分支、状态和人工等待不易独立审阅和复用。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Author in YAML、What you can build 原文描述

将YAML中的状态、条件、工具、人工输入与checkpoint加载为普通Workflow。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 示例与接口边界 编辑核验判断

已核对YAML通过factory加载成普通Workflow,支持状态表达式、工具、人工输入和checkpoint。 声明式格式不自动证明策略安全、流程无环或迁移兼容;文章示例并未提供这些额外保证。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Building trade assistant: How Jefferies optimized front office trading operations with AI

关注的问题

交易分析问题跨多个数据源和业务口径,直接让模型完成查询与图表内容容易失真。

作者的方法

由代理选择数据源和查询,Query Executor实施行级过滤,专用引擎渲染数值图表。

  • 身份与权限
  • 记忆与上下文
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

交易分析问题跨多个数据源和业务口径,直接让模型完成查询与图表内容容易失真。 Solution overview

02 文章用了什么方法

主要方法

由代理选择数据源和查询,Query Executor实施行级过滤,专用引擎渲染数值图表。

回应的问题

交易分析问题跨多个数据源和业务口径,直接让模型完成查询与图表内容容易失真。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Query Executor注入行级过滤,LLM选择查询和呈现,专用引擎渲染数值。 原文依据Lessons learned

这些结论有什么条件

正文提供工程案例而非准确率受控对照;图表渲染正确不证明SQL口径或源数据正确。 Lessons learned

04 总结与启发

我们的理解与启发

把模型的意图解释与确定性数据权限、业务处理和呈现分开。 原文依据Lessons learned

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 交易分析问题跨多个数据源和业务口径,直接让模型完成查询与图表内容容易失真。

primary Solution overview

D1 · 由代理选择数据源和查询,Query Executor实施行级过滤,专用引擎渲染数值图表。

core · described · 对应问题 P1 原文依据

E1 Solution overview 原文描述

交易分析问题跨多个数据源和业务口径,直接让模型完成查询与图表内容容易失真。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 How the solution works、MCP tools 原文描述

由代理选择数据源和查询,Query Executor实施行级过滤,专用引擎渲染数值图表。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Lessons learned 编辑核验判断

已核对Query Executor注入行级过滤,LLM选择查询和呈现,专用引擎渲染数值。 正文提供工程案例而非准确率受控对照;图表渲染正确不证明SQL口径或源数据正确。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

AI Teammates: how monday.com runs production AI agents on Amazon Bedrock

关注的问题

Agent需要像团队成员一样承接多入口任务,状态与责任不能分别散在多个聊天工具。

作者的方法

用SNS/SQS统一消息入口,分层存放活动状态、EFS工作区和S3记录,并以review筛选PR。

  • 状态与恢复
  • 运行时与调度
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

Agent需要像团队成员一样承接多入口任务,状态与责任不能分别散在多个聊天工具。 原文依据

02 文章用了什么方法

主要方法

用SNS/SQS统一消息入口,分层存放活动状态、EFS工作区和S3记录,并以review筛选PR。

回应的问题

Agent需要像团队成员一样承接多入口任务,状态与责任不能分别散在多个聊天工具。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对SNS/SQS统一入口、EFS工作区、S3记录及标准review;约三成PR合并,四分之一在人工前被拦,低revert来自筛选后样本。 原文依据原文依据

这些结论有什么条件

自动合并依赖特定agent×repo×change-class信号;已有业务治理仍需覆盖Agent新行为,不能由集成直接推出普遍安全。 原文依据

04 总结与启发

我们的理解与启发

将任务、身份和交付纳入现有团队系统,并按状态寿命选择存储。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · Agent需要像团队成员一样承接多入口任务,状态与责任不能分别散在多个聊天工具。

primary 原文依据

D1 · 用SNS/SQS统一消息入口,分层存放活动状态、EFS工作区和S3记录,并以review筛选PR。

core · described · 对应问题 P1 原文依据

E1 Three inboxes、State memory sessions 原文描述

Agent需要像团队成员一样承接多入口任务,状态与责任不能分别散在多个聊天工具。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Event path、Five retrofits、Confidence-scored merging 原文描述

用SNS/SQS统一消息入口,分层存放活动状态、EFS工作区和S3记录,并以review筛选PR。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 The signal: A recent rigorous cut 编辑核验判断

已核对SNS/SQS统一入口、EFS工作区、S3记录及标准review;约三成PR合并,四分之一在人工前被拦,低revert来自筛选后样本。 自动合并依赖特定agent×repo×change-class信号;已有业务治理仍需覆盖Agent新行为,不能由集成直接推出普遍安全。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Safety Testing LLM Agents at Scale: From Risk Discovery to Evidence-Grounded Verification

关注的问题

安全测试需要把风险描述转成可观察的状态变化,而不是相信代理自报成功。

作者的方法

组合风险、方法和环境生成安全案例,用初始状态脚本及确定性环境谓词裁决结果。

  • 工具与协议
  • 安全与隔离
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

安全测试需要把风险描述转成可观察的状态变化,而不是相信代理自报成功。 原文依据

02 文章用了什么方法

主要方法

组合风险、方法和环境生成安全案例,用初始状态脚本及确定性环境谓词裁决结果。

回应的问题

安全测试需要把风险描述转成可观察的状态变化,而不是相信代理自报成功。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对三维分类组合、初始状态脚本及状态优先的验证器;控制代理报告失败时直接记零,不调用验证器。 原文依据V-B verification analysis

这些结论有什么条件

良性完整任务与攻击单个违规使用不同成功谓词,70.5%与90.6%的差不能单独证明自适应驱动的因果收益;自动生成谓词仍有误判边界。 V-B verification analysis

04 总结与启发

我们的理解与启发

借鉴可观察证据分层,同时分开成功谓词和分母。 原文依据V-B verification analysis

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 安全测试需要把风险描述转成可观察的状态变化,而不是相信代理自报成功。

primary 原文依据

D1 · 组合风险、方法和环境生成安全案例,用初始状态脚本及确定性环境谓词裁决结果。

core · described · 对应问题 P1 原文依据

E1 IV-B Executable Test Case Construction 原文描述

安全测试需要把风险描述转成可观察的状态变化,而不是相信代理自报成功。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 IV-C3 Evidence-Grounded Verification 原文描述

组合风险、方法和环境生成安全案例,用初始状态脚本及确定性环境谓词裁决结果。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 V-B verification analysis 编辑核验判断

已核对三维分类组合、初始状态脚本及状态优先的验证器;控制代理报告失败时直接记零,不调用验证器。 良性完整任务与攻击单个违规使用不同成功谓词,70.5%与90.6%的差不能单独证明自适应驱动的因果收益;自动生成谓词仍有误判边界。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Best practices for applying Amazon Bedrock Guardrails to code generation workflows

关注的问题

逐段重复扫描代码与历史会消耗 Guardrails 配额,检查应围绕输入和落盘执行边界组织。

作者的方法

在输入、完整工件和执行边界解耦调用Guardrails,以内容缓存和较大批次减少重复扫描。

  • 安全与隔离
  • 文件与工件
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

逐段重复扫描代码与历史会消耗 Guardrails 配额,检查应围绕输入和落盘执行边界组织。 Why guardrails are important

02 文章用了什么方法

主要方法

在输入、完整工件和执行边界解耦调用Guardrails,以内容缓存和较大批次减少重复扫描。

回应的问题

逐段重复扫描代码与历史会消耗 Guardrails 配额,检查应围绕输入和落盘执行边界组织。

原文依据 Architecture patterns 1–6

03 证据支持到哪里

从原文能确认什么

已核对解耦 ApplyGuardrail、内容哈希缓存和千字符批处理;20倍指50改1000字符后的调用频次比例。 Architecture patterns 1–6原文依据

这些结论有什么条件

示例按文件内容哈希缓存,未绑定策略版本;工具包装必须在副作用之前执行才构成闸门,文本检测不等于代码语义安全。 原文依据

04 总结与启发

我们的理解与启发

把检查位置、检测能力与缓存失效条件分别建模。 Architecture patterns 1–6原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 逐段重复扫描代码与历史会消耗 Guardrails 配额,检查应围绕输入和落盘执行边界组织。

primary Why guardrails are important

D1 · 在输入、完整工件和执行边界解耦调用Guardrails,以内容缓存和较大批次减少重复扫描。

core · described · 对应问题 P1 Architecture patterns 1–6

E1 Why guardrails are important 原文描述

逐段重复扫描代码与历史会消耗 Guardrails 配额,检查应围绕输入和落盘执行边界组织。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Architecture patterns 1–6 原文描述

在输入、完整工件和执行边界解耦调用Guardrails,以内容缓存和较大批次减少重复扫描。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 complete decision framework and code examples 编辑核验判断

已核对解耦 ApplyGuardrail、内容哈希缓存和千字符批处理;20倍指50改1000字符后的调用频次比例。 示例按文件内容哈希缓存,未绑定策略版本;工具包装必须在副作用之前执行才构成闸门,文本检测不等于代码语义安全。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

ChannelGuard: Safe Models Do Not Compose into Safe Multi-Agent Systems

关注的问题

多代理的工具、记忆和互相传递内容引入输入过滤覆盖不到的注入路径。

作者的方法

在多类通信边界逐句计算短语库相似度,选择通过、截短或阻断并记录阻断层。

  • 工具与协议
  • 观测与评测
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

多代理的工具、记忆和互相传递内容引入输入过滤覆盖不到的注入路径。 Threat Model

02 文章用了什么方法

主要方法

在多类通信边界逐句计算短语库相似度,选择通过、截短或阻断并记录阻断层。

回应的问题

多代理的工具、记忆和互相传递内容引入输入过滤覆盖不到的注入路径。

原文依据 4.1–4.3 Gate Mechanism

03 证据支持到哪里

从原文能确认什么

已核对逐句短语库相似度、Pass/Compress/Block及多位置闸门;原文承认自适应改写ASR约0.667,输入压缩仍泄漏23.4%。 4.1–4.3 Gate Mechanism7 Discussion and Limitations

这些结论有什么条件

主要比较每组30例、单种子和模拟工具;三值决策的熵上界不等于传递文本的信息量上界,不能推导完整安全保证。 7 Discussion and Limitations

04 总结与启发

我们的理解与启发

边界覆盖值得借鉴,静态签名、压缩保留内容和不确定性处理必须分别评估。 4.1–4.3 Gate Mechanism7 Discussion and Limitations

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 多代理的工具、记忆和互相传递内容引入输入过滤覆盖不到的注入路径。

primary Threat Model

D1 · 在多类通信边界逐句计算短语库相似度,选择通过、截短或阻断并记录阻断层。

core · described · 对应问题 P1 4.1–4.3 Gate Mechanism

E1 Threat Model 原文描述

多代理的工具、记忆和互相传递内容引入输入过滤覆盖不到的注入路径。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 4.1–4.3 Gate Mechanism 原文描述

在多类通信边界逐句计算短语库相似度,选择通过、截短或阻断并记录阻断层。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 7 Discussion and Limitations 编辑核验判断

已核对逐句短语库相似度、Pass/Compress/Block及多位置闸门;原文承认自适应改写ASR约0.667,输入压缩仍泄漏23.4%。 主要比较每组30例、单种子和模拟工具;三值决策的熵上界不等于传递文本的信息量上界,不能推导完整安全保证。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

JANUS: Foreseeing Latent Risk for Long-Horizon Agent Safety

关注的问题

长任务中的风险可能尚未显露,护栏需要依据轨迹前缀判断后续危险。

作者的方法

共享模型先预测未来摘要再进行安全裁决,以耦合奖励联合训练两项能力。

  • 安全与隔离
  • 工具与协议
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

长任务中的风险可能尚未显露,护栏需要依据轨迹前缀判断后续危险。 Introduction

02 文章用了什么方法

主要方法

共享模型先预测未来摘要再进行安全裁决,以耦合奖励联合训练两项能力。

回应的问题

长任务中的风险可能尚未显露,护栏需要依据轨迹前缀判断后续危险。

原文依据 CoAA-RL; Inference

03 证据支持到哪里

从原文能确认什么

已核对共享模型的未来摘要与裁决两项训练、耦合奖励及推理时两阶段调用;并非仅增加一个提示词。 CoAA-RL; InferenceLimitations; Table 1

这些结论有什么条件

训练轨迹来自多代理模拟,外部工具和新政策泛化未充分刻画;正文表格混用Vanguard名称,按具体机制识别结论。 Limitations; Table 1

04 总结与启发

我们的理解与启发

区分预测未来风险与已经发生违规的证据,预测应标为概率判断。 CoAA-RL; InferenceLimitations; Table 1

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 长任务中的风险可能尚未显露,护栏需要依据轨迹前缀判断后续危险。

primary Introduction

D1 · 共享模型先预测未来摘要再进行安全裁决,以耦合奖励联合训练两项能力。

core · described · 对应问题 P1 CoAA-RL; Inference

E1 Introduction 原文描述

长任务中的风险可能尚未显露,护栏需要依据轨迹前缀判断后续危险。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 CoAA-RL; Inference 原文描述

共享模型先预测未来摘要再进行安全裁决,以耦合奖励联合训练两项能力。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Limitations; Table 1 编辑核验判断

已核对共享模型的未来摘要与裁决两项训练、耦合奖励及推理时两阶段调用;并非仅增加一个提示词。 训练轨迹来自多代理模拟,外部工具和新政策泛化未充分刻画;正文表格混用Vanguard名称,按具体机制识别结论。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Evaluating AI Agents: A production blueprint with Strands and AgentCore

关注的问题

生产代理需要同时评价工具使用、推理和最终交付,接口正常不代表任务正确。

作者的方法

把确定性工具评分、推理judge和输出质量分层,结合人工校准与多次通过口径。

  • 工具与协议
  • 观测与评测
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

生产代理需要同时评价工具使用、推理和最终交付,接口正常不代表任务正确。 原文依据

02 文章用了什么方法

主要方法

把确定性工具评分、推理judge和输出质量分层,结合人工校准与多次通过口径。

回应的问题

生产代理需要同时评价工具使用、推理和最终交付,接口正常不代表任务正确。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对确定性评分、模型评分与人工校准的分工及多次通过口径;生产失败回流为用例。 原文依据Results and impact

这些结论有什么条件

95/85/90门槛是案例设置,87%到98%等为团队前后报告,不能归因到单一组件或直接移植为通用标准。 Results and impact

04 总结与启发

我们的理解与启发

按模块选择证据与评分方式,再用任务结果汇总,不只统计工具路径。 原文依据Results and impact

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 生产代理需要同时评价工具使用、推理和最终交付,接口正常不代表任务正确。

primary 原文依据

D1 · 把确定性工具评分、推理judge和输出质量分层,结合人工校准与多次通过口径。

core · described · 对应问题 P1 原文依据

E1 Why agent evaluation is different 原文描述

生产代理需要同时评价工具使用、推理和最终交付,接口正常不代表任务正确。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Three types of graders; three-layer assessment 原文描述

把确定性工具评分、推理judge和输出质量分层,结合人工校准与多次通过口径。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Results and impact 编辑核验判断

已核对确定性评分、模型评分与人工校准的分工及多次通过口径;生产失败回流为用例。 95/85/90门槛是案例设置,87%到98%等为团队前后报告,不能归因到单一组件或直接移植为通用标准。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How Outtake built a cyber investigator on Claude

关注的问题

长时间网络调查需要持久工作空间、灵活工具与外围约束共同支持。

作者的方法

以文件系统和bash支持开放调查,把必须成立的约束移到harness,工具改进交由独立代理和人审。

  • 记忆与上下文
  • 工具与协议
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

长时间网络调查需要持久工作空间、灵活工具与外围约束共同支持。 原文依据

02 文章用了什么方法

主要方法

以文件系统和bash支持开放调查,把必须成立的约束移到harness,工具改进交由独立代理和人审。

回应的问题

长时间网络调查需要持久工作空间、灵活工具与外围约束共同支持。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对从Claude Code到Agent SDK、文件系统与bash、编排层硬约束以及独立编码代理提出工具改进后由人判断。 原文依据原文依据

这些结论有什么条件

这是团队工程经验,未给出各组件受控效果;blastbox容许代理被劫持假设,不意味着任意网络内容可信。 原文依据

04 总结与启发

我们的理解与启发

把始终必须执行的规则放到宿主,把领域判断保留给代理。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 长时间网络调查需要持久工作空间、灵活工具与外围约束共同支持。

primary 原文依据

D1 · 以文件系统和bash支持开放调查,把必须成立的约束移到harness,工具改进交由独立代理和人审。

core · described · 对应问题 P1 原文依据

E1 Agentic offense needs agentic defense 原文描述

长时间网络调查需要持久工作空间、灵活工具与外围约束共同支持。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Step 3; Prompts are suggestions 原文描述

以文件系统和bash支持开放调查,把必须成立的约束移到harness,工具改进交由独立代理和人审。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Protecting your agents; Step 4 编辑核验判断

已核对从Claude Code到Agent SDK、文件系统与bash、编排层硬约束以及独立编码代理提出工具改进后由人判断。 这是团队工程经验,未给出各组件受控效果;blastbox容许代理被劫持假设,不意味着任意网络内容可信。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

OpenSkillRisk: Benchmarking Agent Safety When Using Real-World Risky Third-Party Skills

关注的问题

公开技能中的风险既有无条件恶意,也有取决于用户授权范围的操作。

作者的方法

用筛选后的真实技能配合良性任务,在模拟外部服务中分别记录风险执行和风险意识。

  • 安全与隔离
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

公开技能中的风险既有无条件恶意,也有取决于用户授权范围的操作。 3.1 Skills Selection

还需处理的问题

防护可能通过过度拒绝牺牲正常任务。 原文依据

02 文章用了什么方法

主要方法

用筛选后的真实技能配合良性任务,在模拟外部服务中分别记录风险执行和风险意识。

回应的问题

公开技能中的风险既有无条件恶意,也有取决于用户授权范围的操作。

原文依据 原文依据

配套设计

单独报告良性技能过度防御,并区分阻断后放弃与安全完成。

回应的问题

防护可能通过过度拒绝牺牲正常任务。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对263个筛选技能、模拟外部服务与行为五分类;意识到风险和阻止风险分开计分。 原文依据4.5; Appendix D.2

这些结论有什么条件

主动加载防护技能在40个良性技能上的平均过度防御22.50%,被动为1.88%;Fsafe不直接计入良性任务完成,不能替代效用指标。 4.5; Appendix D.2

04 总结与启发

我们的理解与启发

同时保留风险识别、实际执行和安全完成三个维度。 原文依据4.5; Appendix D.2

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 公开技能中的风险既有无条件恶意,也有取决于用户授权范围的操作。

primary 3.1 Skills Selection

P2 · 防护可能通过过度拒绝牺牲正常任务。

secondary · ↳ P1 原文依据

D1 · 用筛选后的真实技能配合良性任务,在模拟外部服务中分别记录风险执行和风险意识。

core · described · 对应问题 P1 原文依据

D2 · 单独报告良性技能过度防御,并区分阻断后放弃与安全完成。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 3.1 Skills Selection 原文描述

公开技能中的风险既有无条件恶意,也有取决于用户授权范围的操作。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 3.2–3.4 task and behavior assessment 原文描述

用筛选后的真实技能配合良性任务,在模拟外部服务中分别记录风险执行和风险意识。 单独报告良性技能过度防御,并区分阻断后放弃与安全完成。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 4.5; Appendix D.2 编辑核验判断

已核对263个筛选技能、模拟外部服务与行为五分类;意识到风险和阻止风险分开计分。 主动加载防护技能在40个良性技能上的平均过度防御22.50%,被动为1.88%;Fsafe不直接计入良性任务完成,不能替代效用指标。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Detecting silent agent failures with Amazon Bedrock AgentCore optimization

关注的问题

成功结束且无异常的会话也可能跳过前置操作或编造结果。

作者的方法

在逐会话失败分类后跨会话聚类,剪枝执行图并定位根因及影响范围。

  • 观测与评测
  • 工具与协议
  • 运行时与调度
阅读推荐收起推荐

01 背景与问题

成功结束且无异常的会话也可能跳过前置操作或编造结果。 Failure pattern discovery

02 文章用了什么方法

主要方法

在逐会话失败分类后跨会话聚类,剪枝执行图并定位根因及影响范围。

回应的问题

成功结束且无异常的会话也可能跳过前置操作或编造结果。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对逐会话11类失败、跨会话聚类、执行图剪枝与根因位置;示例只包含10次会话。 原文依据Seeing insights in action

这些结论有什么条件

聚类数量描述分析样本内影响范围;根因是系统推断,增强提示词不等于强制工具执行。 Seeing insights in action

04 总结与启发

我们的理解与启发

先定位具体失败及证据,再把根因假设与修复建议分开。 原文依据Seeing insights in action

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 成功结束且无异常的会话也可能跳过前置操作或编造结果。

primary Failure pattern discovery

D1 · 在逐会话失败分类后跨会话聚类,剪枝执行图并定位根因及影响范围。

core · described · 对应问题 P1 原文依据

E1 Failure pattern discovery 原文描述

成功结束且无异常的会话也可能跳过前置操作或编造结果。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 User intent analysis; execution insights 原文描述

在逐会话失败分类后跨会话聚类,剪枝执行图并定位根因及影响范围。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Seeing insights in action 编辑核验判断

已核对逐会话11类失败、跨会话聚类、执行图剪枝与根因位置;示例只包含10次会话。 聚类数量描述分析样本内影响范围;根因是系统推断,增强提示词不等于强制工具执行。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

The Blueprint: How Voicify makes AI-enabled ordering a delight for customers

关注的问题

电话订餐要在低延迟下处理复杂菜单并准确提交POS订单。

作者的方法

按对话需要渐进加载菜单,经POS验证再提交订单,并组合预留和按需推理容量。

  • 观测与评测
  • 安全与隔离
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

电话订餐要在低延迟下处理复杂菜单并准确提交POS订单。 The challenge

02 文章用了什么方法

主要方法

按对话需要渐进加载菜单,经POS验证再提交订单,并组合预留和按需推理容量。

回应的问题

电话订餐要在低延迟下处理复杂菜单并准确提交POS订单。

原文依据 The details; The solution

03 证据支持到哪里

从原文能确认什么

已核对渐进取菜单、语音编排与提交前POS验证;吞吐预留和按需容量共同应对流量尖峰。 The details; The solutionThe outcome

这些结论有什么条件

25%至30%节省与100%可用是客户案例自报,未给出统一测试窗口;未来主动下单仍是展望。 The outcome

04 总结与启发

我们的理解与启发

让确定性订单校验承接最终写入,按对话需要加载菜单细节。 The details; The solutionThe outcome

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 电话订餐要在低延迟下处理复杂菜单并准确提交POS订单。

primary The challenge

D1 · 按对话需要渐进加载菜单,经POS验证再提交订单,并组合预留和按需推理容量。

core · described · 对应问题 P1 The details; The solution

E1 The challenge 原文描述

电话订餐要在低延迟下处理复杂菜单并准确提交POS订单。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 The details; The solution 原文描述

按对话需要渐进加载菜单,经POS验证再提交订单,并组合预留和按需推理容量。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 The outcome 编辑核验判断

已核对渐进取菜单、语音编排与提交前POS验证;吞吐预留和按需容量共同应对流量尖峰。 25%至30%节省与100%可用是客户案例自报,未给出统一测试窗口;未来主动下单仍是展望。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How Anthropic secures its AI-native software development lifecycle

关注的问题

AI扩大代码产量后,安全审查需要扩展吞吐并保留责任和权限边界。

作者的方法

结合VM出网边界、CI审查与风险抽样,将工具调用、批准和代理间消息送入审计。

  • 身份与权限
  • 文件与工件
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

AI扩大代码产量后,安全审查需要扩展吞吐并保留责任和权限边界。 原文依据

02 文章用了什么方法

主要方法

结合VM出网边界、CI审查与风险抽样,将工具调用、批准和代理间消息送入审计。

回应的问题

AI扩大代码产量后,安全审查需要扩展吞吐并保留责任和权限边界。

原文依据 Code; Test CI; Monitor

03 证据支持到哪里

从原文能确认什么

已核对VM出网限制、CI硬门、多专向审查和风险抽样;告警代理曾经借Slack委托别的代理写修复,人审挡住了发布。 Code; Test CI; MonitorGovernance

这些结论有什么条件

80%代码与16%到54%审查评论均属内部统计,评论比例不等于漏洞召回;不同上下文也不保证模型错误独立。 Governance

04 总结与启发

我们的理解与启发

权限图需要覆盖代理间委托,治理要检查审查循环本身。 Code; Test CI; MonitorGovernance

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · AI扩大代码产量后,安全审查需要扩展吞吐并保留责任和权限边界。

primary 原文依据

D1 · 结合VM出网边界、CI审查与风险抽样,将工具调用、批准和代理间消息送入审计。

core · described · 对应问题 P1 Code; Test CI; Monitor

E1 The evolving software development lifecycle 原文描述

AI扩大代码产量后,安全审查需要扩展吞吐并保留责任和权限边界。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Code; Test CI; Monitor 原文描述

结合VM出网边界、CI审查与风险抽样,将工具调用、批准和代理间消息送入审计。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Governance 编辑核验判断

已核对VM出网限制、CI硬门、多专向审查和风险抽样;告警代理曾经借Slack委托别的代理写修复,人审挡住了发布。 80%代码与16%到54%审查评论均属内部统计,评论比例不等于漏洞召回;不同上下文也不保证模型错误独立。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Agents SDK reduces MCP schema conversion, adds exposure controls for MCP in Think and Code Mode SDK adds direct host APIs

关注的问题

同一MCP目录反复转换schema和多渠道重复暴露工具浪费上下文与运行成本。

作者的方法

缓存活连接的转换schema,单独控制自动工具暴露,并提供Code Mode直接宿主API。

  • 工具与协议
  • 状态与恢复
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

同一MCP目录反复转换schema和多渠道重复暴露工具浪费上下文与运行成本。 Release introduction

还需处理的问题

同一工具同时出现在自动列表和Code Mode中。 原文依据

02 文章用了什么方法

主要方法

缓存活连接的转换schema,单独控制自动工具暴露,并提供Code Mode直接宿主API。

回应的问题

同一MCP目录反复转换schema和多渠道重复暴露工具浪费上下文与运行成本。

原文依据 原文依据

配套设计

用includeMcpTools关闭自动getAITools暴露,保留发现及直接调用。

回应的问题

同一工具同时出现在自动列表和Code Mode中。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对活连接目录缓存、includeMcpTools关闭自动暴露,以及durable runtime的search/describe/execute与审批暂停接口。 原文依据Upgrade and API scope

这些结论有什么条件

关闭自动暴露不关闭发现、直调或Code Mode连接;这是发布说明,没有给出性能测量。 Upgrade and API scope

04 总结与启发

我们的理解与启发

把目录发现、模型可见性和调用权限分别控制。 原文依据Upgrade and API scope

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 同一MCP目录反复转换schema和多渠道重复暴露工具浪费上下文与运行成本。

primary Release introduction

P2 · 同一工具同时出现在自动列表和Code Mode中。

secondary · ↳ P1 原文依据

D1 · 缓存活连接的转换schema,单独控制自动工具暴露,并提供Code Mode直接宿主API。

core · described · 对应问题 P1 原文依据

D2 · 用includeMcpTools关闭自动getAITools暴露,保留发现及直接调用。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Release introduction 原文描述

同一MCP目录反复转换schema和多渠道重复暴露工具浪费上下文与运行成本。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Control direct MCP tool exposure; direct host APIs 原文描述

缓存活连接的转换schema,单独控制自动工具暴露,并提供Code Mode直接宿主API。 用includeMcpTools关闭自动getAITools暴露,保留发现及直接调用。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Upgrade and API scope 编辑核验判断

已核对活连接目录缓存、includeMcpTools关闭自动暴露,以及durable runtime的search/describe/execute与审批暂停接口。 关闭自动暴露不关闭发现、直调或Code Mode连接;这是发布说明,没有给出性能测量。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Build agentic full-stack apps with Genkit

关注的问题

全栈对话应用需要统一状态、流式协议、工具暂停与前端续接。

作者的方法

统一对话和流式接口,按应用需要选择客户端状态或服务端快照,并支持暂停和后台任务。

  • 状态与恢复
  • 工具与协议
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

全栈对话应用需要统一状态、流式协议、工具暂停与前端续接。 Agents API introduction

还需处理的问题

用户返回的恢复参数可能与暂停调用不符。 原文依据

02 文章用了什么方法

主要方法

统一对话和流式接口,按应用需要选择客户端状态或服务端快照,并支持暂停和后台任务。

回应的问题

全栈对话应用需要统一状态、流式协议、工具暂停与前端续接。

原文依据 原文依据

配套设计

运行时依据session history核对恢复输入。

回应的问题

用户返回的恢复参数可能与暂停调用不符。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对客户端或服务端状态、session与snapshot分支、审批恢复校验和后台pending snapshot。 原文依据原文依据

这些结论有什么条件

API仍是预览版;请求断开后的继续工作不自动证明进程崩溃后所有副作用恰好一次。 原文依据

04 总结与启发

我们的理解与启发

让UI状态、对话状态和可下载产物有清晰生命周期。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 全栈对话应用需要统一状态、流式协议、工具暂停与前端续接。

primary Agents API introduction

P2 · 用户返回的恢复参数可能与暂停调用不符。

secondary · ↳ P1 原文依据

D1 · 统一对话和流式接口,按应用需要选择客户端状态或服务端快照,并支持暂停和后台任务。

core · described · 对应问题 P1 原文依据

D2 · 运行时依据session history核对恢复输入。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Agents API introduction 原文描述

全栈对话应用需要统一状态、流式协议、工具暂停与前端续接。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 State; Human approval; Work outlives request 原文描述

统一对话和流式接口,按应用需要选择客户端状态或服务端快照,并支持暂停和后台任务。 运行时依据session history核对恢复输入。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Preview notice; When to reach for ADK 编辑核验判断

已核对客户端或服务端状态、session与snapshot分支、审批恢复校验和后台pending snapshot。 API仍是预览版;请求断开后的继续工作不自动证明进程崩溃后所有副作用恰好一次。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Know Your Agent: Reconnaissance-Driven Pentesting of AI Agents

关注的问题

代理暴露的工具和行为信息会帮助攻击者构造更贴合任务的间接注入。

作者的方法

以结构化目标资料库记录侦察信息,根据战术先决条件选择下一次探测或尝试。

  • 工具与协议
  • 身份与权限
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

代理暴露的工具和行为信息会帮助攻击者构造更贴合任务的间接注入。 III Threat Model

02 文章用了什么方法

主要方法

以结构化目标资料库记录侦察信息,根据战术先决条件选择下一次探测或尝试。

回应的问题

代理暴露的工具和行为信息会帮助攻击者构造更贴合任务的间接注入。

原文依据 V KYA Framework

03 证据支持到哪里

从原文能确认什么

已核对目标资料库、带先决条件的战术库以及侦察和尝试之间的反馈;OpenHands案例是5个小仓库、70组合、3次。 V KYA FrameworkVI-C OpenHands case study

这些结论有什么条件

21.9%是该设置总成功率;任务合理性解释属于作者归因,不能从危害分组直接证明模型内部拒绝机制。 VI-C OpenHands case study

04 总结与启发

我们的理解与启发

把工具元数据和错误消息也纳入攻击面分析。 V KYA FrameworkVI-C OpenHands case study

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 代理暴露的工具和行为信息会帮助攻击者构造更贴合任务的间接注入。

primary III Threat Model

D1 · 以结构化目标资料库记录侦察信息,根据战术先决条件选择下一次探测或尝试。

core · described · 对应问题 P1 V KYA Framework

E1 III Threat Model 原文描述

代理暴露的工具和行为信息会帮助攻击者构造更贴合任务的间接注入。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 V KYA Framework 原文描述

以结构化目标资料库记录侦察信息,根据战术先决条件选择下一次探测或尝试。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 VI-C OpenHands case study 编辑核验判断

已核对目标资料库、带先决条件的战术库以及侦察和尝试之间的反馈;OpenHands案例是5个小仓库、70组合、3次。 21.9%是该设置总成功率;任务合理性解释属于作者归因,不能从危害分组直接证明模型内部拒绝机制。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

How KTern.AI built agentic AI for SAP on Amazon Bedrock AgentCore

关注的问题

SAP转换项目跨会话跨工具,要求项目记忆、客户隔离与过程可观测。

作者的方法

以SAP领域配置组合专向代理,复用AgentCore运行、项目记忆、身份和工具网关。

  • 工具与协议
  • 身份与权限
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

SAP转换项目跨会话跨工具,要求项目记忆、客户隔离与过程可观测。 The challenge

02 文章用了什么方法

主要方法

以SAP领域配置组合专向代理,复用AgentCore运行、项目记忆、身份和工具网关。

回应的问题

SAP转换项目跨会话跨工具,要求项目记忆、客户隔离与过程可观测。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对AgentCore上的专向代理、项目记忆、MCP工具接入、PrivateLink及配置驱动的组合。 原文依据Lessons learned

这些结论有什么条件

部署从周到小时是团队经验,托管服务配置不替代具体SAP权限与数据范围设计。 Lessons learned

04 总结与启发

我们的理解与启发

先设计项目记忆和权限模型,再组合领域代理。 原文依据Lessons learned

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · SAP转换项目跨会话跨工具,要求项目记忆、客户隔离与过程可观测。

primary The challenge

D1 · 以SAP领域配置组合专向代理,复用AgentCore运行、项目记忆、身份和工具网关。

core · described · 对应问题 P1 原文依据

E1 The challenge 原文描述

SAP转换项目跨会话跨工具,要求项目记忆、客户隔离与过程可观测。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Architecture; AgentCore components 原文描述

以SAP领域配置组合专向代理,复用AgentCore运行、项目记忆、身份和工具网关。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Lessons learned 编辑核验判断

已核对AgentCore上的专向代理、项目记忆、MCP工具接入、PrivateLink及配置驱动的组合。 部署从周到小时是团队经验,托管服务配置不替代具体SAP权限与数据范围设计。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments

关注的问题

x402中介在HTTP验证与链上结算之间承担付款授权和费用边界。

作者的方法

按八条支付规则发现适用能力,对应核对HTTP验证结果与链上实际收据。

  • 身份与权限
  • 观测与评测
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

x402中介在HTTP验证与链上结算之间承担付款授权和费用边界。 原文依据

02 文章用了什么方法

主要方法

按八条支付规则发现适用能力,对应核对HTTP验证结果与链上实际收据。

回应的问题

x402中介在HTTP验证与链上结算之间承担付款授权和费用边界。

原文依据 Security Rules; 5.2 checker

03 证据支持到哪里

从原文能确认什么

已核对八条规则、能力发现后按适用项检查及HTTP与链上收据对应;表2区分已验证利用、高风险证据与不可利用。 Security Rules; 5.2 checker原文依据

这些结论有什么条件

15个服务均违反规则不等于都遭到资产盗取;放行发生在verify还是settle影响危害,统计窗口与实现版本限制适用范围。 原文依据

04 总结与启发

我们的理解与启发

区分证明有效、结算成功、资源放行和赞助费用四个状态。 Security Rules; 5.2 checker原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · x402中介在HTTP验证与链上结算之间承担付款授权和费用边界。

primary 原文依据

D1 · 按八条支付规则发现适用能力,对应核对HTTP验证结果与链上实际收据。

core · described · 对应问题 P1 Security Rules; 5.2 checker

E1 Introduction; 3.1 Threat Model 原文描述

x402中介在HTTP验证与链上结算之间承担付款授权和费用边界。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Security Rules; 5.2 checker 原文描述

按八条支付规则发现适用能力,对应核对HTTP验证结果与链上实际收据。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Table 2; Real World Evaluation 编辑核验判断

已核对八条规则、能力发现后按适用项检查及HTTP与链上收据对应;表2区分已验证利用、高风险证据与不可利用。 15个服务均违反规则不等于都遭到资产盗取;放行发生在verify还是settle影响危害,统计窗口与实现版本限制适用范围。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Twin Agent: Context Residual Compression for Privilege Separated Agents

关注的问题

有权限的代理直接阅读不可信材料容易把注入转成实际操作。

作者的方法

Explore读取不可信区域,Safe保留权限和权威轨迹,两者仅传递限长且经过检测的残差信息。

  • 身份与权限
  • 安全与隔离
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

有权限的代理直接阅读不可信材料容易把注入转成实际操作。 3.1 Problem Statement

02 文章用了什么方法

主要方法

Explore读取不可信区域,Safe保留权限和权威轨迹,两者仅传递限长且经过检测的残差信息。

回应的问题

有权限的代理直接阅读不可信材料容易把注入转成实际操作。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Explore读取不可信区域、Safe持有权限和权威轨迹、限长残差信息与检测器;式11是设计目标而非实际求解算法。 原文依据4.3; Limitations

这些结论有什么条件

安全依赖短注入难以同时绕过检测器和模型的经验假设,原文明确没有形式化保证;SWE设置只隔离issue而非所有仓库内容。 4.3; Limitations

04 总结与启发

我们的理解与启发

记录每种实例中真正隔离的输入区域及仍可传递的信息。 原文依据4.3; Limitations

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 有权限的代理直接阅读不可信材料容易把注入转成实际操作。

primary 3.1 Problem Statement

D1 · Explore读取不可信区域,Safe保留权限和权威轨迹,两者仅传递限长且经过检测的残差信息。

core · described · 对应问题 P1 原文依据

E1 3.1 Problem Statement 原文描述

有权限的代理直接阅读不可信材料容易把注入转成实际操作。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 3.3 Residual Compression; 4 instantiations 原文描述

Explore读取不可信区域,Safe保留权限和权威轨迹,两者仅传递限长且经过检测的残差信息。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 4.3; Limitations 编辑核验判断

已核对Explore读取不可信区域、Safe持有权限和权威轨迹、限长残差信息与检测器;式11是设计目标而非实际求解算法。 安全依赖短注入难以同时绕过检测器和模型的经验假设,原文明确没有形式化保证;SWE设置只隔离issue而非所有仓库内容。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Building Agents that Act on Your Behalf with Toolboxes in Foundry

关注的问题

多租户工具调用要传递最终用户身份,避免各代理重复实现凭据交换。

作者的方法

将OAuth连接配置和版本化toolbox交给平台,代理通过单MCP端点使用用户委托身份。

  • 工具与协议
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

多租户工具调用要传递最终用户身份,避免各代理重复实现凭据交换。 Why is this hard

02 文章用了什么方法

主要方法

将OAuth连接配置和版本化toolbox交给平台,代理通过单MCP端点使用用户委托身份。

回应的问题

多租户工具调用要传递最终用户身份,避免各代理重复实现凭据交换。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对connection配置OAuth、版本化toolbox和hosted agent使用单MCP端点;不同auth模式代表不同主体。 原文依据Governed by default

这些结论有什么条件

示例require_approval为never,OBO身份传递本身不等于逐次用户审批;输入输出护栏不是注入绝对不可能的证明。 Governed by default

04 总结与启发

我们的理解与启发

把身份交换、资源授权与操作确认分别表达。 原文依据Governed by default

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 多租户工具调用要传递最终用户身份,避免各代理重复实现凭据交换。

primary Why is this hard

D1 · 将OAuth连接配置和版本化toolbox交给平台,代理通过单MCP端点使用用户委托身份。

core · described · 对应问题 P1 原文依据

E1 Why is this hard 原文描述

多租户工具调用要传递最终用户身份,避免各代理重复实现凭据交换。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 How Toolbox solves it; auth types 原文描述

将OAuth连接配置和版本化toolbox交给平台,代理通过单MCP端点使用用户委托身份。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Governed by default 编辑核验判断

已核对connection配置OAuth、版本化toolbox和hosted agent使用单MCP端点;不同auth模式代表不同主体。 示例require_approval为never,OBO身份传递本身不等于逐次用户审批;输入输出护栏不是注入绝对不可能的证明。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Agents can respond to MCP elicitation requests

关注的问题

MCP调用中可能需要用户提供表单信息或完成站外授权。

作者的方法

把MCP表单或URL请求转给用户,接收同意、拒绝或取消,并恢复原调用。

  • 工具与协议
  • 状态与恢复
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

MCP调用中可能需要用户提供表单信息或完成站外授权。 Elicitation introduction

还需处理的问题

休眠后原处理回调不再驻留内存。 Handler registration

02 文章用了什么方法

主要方法

把MCP表单或URL请求转给用户,接收同意、拒绝或取消,并恢复原调用。

回应的问题

MCP调用中可能需要用户提供表单信息或完成站外授权。

原文依据 Handler registration

配套设计

持久保存宣告模式,在onStart重新绑定对应处理函数。

回应的问题

休眠后原处理回调不再驻留内存。

原文依据 Handler registration

03 证据支持到哪里

从原文能确认什么

已核对form与URL两种模式、accept/decline/cancel及配置后才宣告能力;休眠保存模式,回调在onStart重新绑定。 Handler registration原文依据

这些结论有什么条件

SDK提供转发机制,具体UI仍需实现;URL打开需要用户同意,不能由代理自行代答敏感授权。 原文依据

04 总结与启发

我们的理解与启发

把用户输入作为明确的协议事件并保留请求来源。 Handler registration原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · MCP调用中可能需要用户提供表单信息或完成站外授权。

primary Elicitation introduction

P2 · 休眠后原处理回调不再驻留内存。

secondary · ↳ P1 Handler registration

D1 · 把MCP表单或URL请求转给用户,接收同意、拒绝或取消,并恢复原调用。

core · described · 对应问题 P1 Handler registration

D2 · 持久保存宣告模式,在onStart重新绑定对应处理函数。

supporting · described · 对应问题 P2 · 支撑 D1 Handler registration

E1 Elicitation introduction 原文描述

MCP调用中可能需要用户提供表单信息或完成站外授权。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Handler registration 原文描述

把MCP表单或URL请求转给用户,接收同意、拒绝或取消,并恢复原调用。 持久保存宣告模式,在onStart重新绑定对应处理函数。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Hibernation and advertised modes 编辑核验判断

已核对form与URL两种模式、accept/decline/cancel及配置后才宣告能力;休眠保存模式,回调在onStart重新绑定。 SDK提供转发机制,具体UI仍需实现;URL打开需要用户同意,不能由代理自行代答敏感授权。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Build specialized agent workflows for your business with Amazon Quick and NVIDIA NeMo Agent Toolkit

关注的问题

企业聊天入口需要调用有结构的供应链分析流程并返回证据包。

作者的方法

由Quick经Gateway和Lambda调用NeMo,顺序组织采购、库存、政策与建议函数并返回证据包。

  • 状态与恢复
  • 工具与协议
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

企业聊天入口需要调用有结构的供应链分析流程并返回证据包。 Architecture overview

02 文章用了什么方法

主要方法

由Quick经Gateway和Lambda调用NeMo,顺序组织采购、库存、政策与建议函数并返回证据包。

回应的问题

企业聊天入口需要调用有结构的供应链分析流程并返回证据包。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对Quick经Gateway与Lambda调用Runtime,NeMo顺序组织采购、库存、客户、政策和建议函数。 原文依据Security considerations

这些结论有什么条件

原文明示这是demo,Gateway的AuthorizerType为NONE,自定义header不构成授权;生产身份与写入审批属于建议。 Security considerations

04 总结与启发

我们的理解与启发

区分演示数据流和生产必需控制,不把待加控制写成已交付。 原文依据Security considerations

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 企业聊天入口需要调用有结构的供应链分析流程并返回证据包。

primary Architecture overview

D1 · 由Quick经Gateway和Lambda调用NeMo,顺序组织采购、库存、政策与建议函数并返回证据包。

core · described · 对应问题 P1 原文依据

E1 Architecture overview 原文描述

企业聊天入口需要调用有结构的供应链分析流程并返回证据包。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 What runs inside NeMo workflow 原文描述

由Quick经Gateway和Lambda调用NeMo,顺序组织采购、库存、政策与建议函数并返回证据包。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Security considerations 编辑核验判断

已核对Quick经Gateway与Lambda调用Runtime,NeMo顺序组织采购、库存、客户、政策和建议函数。 原文明示这是demo,Gateway的AuthorizerType为NONE,自定义header不构成授权;生产身份与写入审批属于建议。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Agents SDK v0.17.0:后台子 Agent 必须是持久运行实体

关注的问题

后台子任务不能依赖发起对话的连接和单个进程存活。

作者的方法

把后台子任务保存为耐久句柄,提供预算、取消和milestone,并统一turn入场路径。

  • 状态与恢复
  • 文件与工件
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

后台子任务不能依赖发起对话的连接和单个进程存活。 Release introduction

还需处理的问题

嵌套阻塞调用可能造成死锁。 原文依据

02 文章用了什么方法

主要方法

把后台子任务保存为耐久句柄,提供预算、取消和milestone,并统一turn入场路径。

回应的问题

后台子任务不能依赖发起对话的连接和单个进程存活。

原文依据 原文依据

配套设计

通过统一runTurn入场路径拒绝嵌套阻塞式请求。

回应的问题

嵌套阻塞调用可能造成死锁。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对durable后台句柄、预算取消、milestone与统一入场路径;恢复包括修补中断工具记录和重连状态。 原文依据原文依据

这些结论有什么条件

完成通知限定happy path的exactly-once;修补转录不代表撤销外部操作,server actions仍是实验API。 原文依据

04 总结与启发

我们的理解与启发

把任务运行、进度信号和最终副作用分别追踪。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 后台子任务不能依赖发起对话的连接和单个进程存活。

primary Release introduction

P2 · 嵌套阻塞调用可能造成死锁。

secondary · ↳ P1 原文依据

D1 · 把后台子任务保存为耐久句柄,提供预算、取消和milestone,并统一turn入场路径。

core · described · 对应问题 P1 原文依据

D2 · 通过统一runTurn入场路径拒绝嵌套阻塞式请求。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Release introduction 原文描述

后台子任务不能依赖发起对话的连接和单个进程存活。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Background sub-agents; runTurn 原文描述

把后台子任务保存为耐久句柄,提供预算、取消和milestone,并统一turn入场路径。 通过统一runTurn入场路径拒绝嵌套阻塞式请求。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Recovery; experimental actions 编辑核验判断

已核对durable后台句柄、预算取消、milestone与统一入场路径;恢复包括修补中断工具记录和重连状态。 完成通知限定happy path的exactly-once;修补转录不代表撤销外部操作,server actions仍是实验API。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Secure Agent Workspace:端点只展示,Agent 在受管边界内执行

关注的问题

企业长期代理需要统一管理执行环境、身份、出网和工具边界。

作者的方法

把本地端点作为交互层,代理运行于每用户受管VM,并叠加出网、签名策略和凭据代理。

  • 身份与权限
  • 文件与工件
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

企业长期代理需要统一管理执行环境、身份、出网和工具边界。 原文依据

02 文章用了什么方法

主要方法

把本地端点作为交互层,代理运行于每用户受管VM,并叠加出网、签名策略和凭据代理。

回应的问题

企业长期代理需要统一管理执行环境、身份、出网和工具边界。

原文依据 Perimeter and runtime phases

03 证据支持到哪里

从原文能确认什么

已核对每用户VM、外部默认拒绝网络与内部沙箱、签名策略和凭据代理;蓝图绑定目标、工具和审查范围。 Perimeter and runtime phases原文依据

这些结论有什么条件

这是参考设计的分阶段要求,不是已有部署的覆盖证明或安全测量;VM隔离与工具授权承担不同职责。 原文依据

04 总结与启发

我们的理解与启发

按外部访问、内部执行、凭据和审计分别列出责任方。 Perimeter and runtime phases原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 企业长期代理需要统一管理执行环境、身份、出网和工具边界。

primary 原文依据

D1 · 把本地端点作为交互层,代理运行于每用户受管VM,并叠加出网、签名策略和凭据代理。

core · described · 对应问题 P1 Perimeter and runtime phases

E1 Reference Design introduction 原文描述

企业长期代理需要统一管理执行环境、身份、出网和工具边界。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Perimeter and runtime phases 原文描述

把本地端点作为交互层,代理运行于每用户受管VM,并叠加出网、签名策略和凭据代理。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Blueprints; deployment guidance 编辑核验判断

已核对每用户VM、外部默认拒绝网络与内部沙箱、签名策略和凭据代理;蓝图绑定目标、工具和审查范围。 这是参考设计的分阶段要求,不是已有部署的覆盖证明或安全测量;VM隔离与工具授权承担不同职责。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Arca:在等待边界保存“余下程序”,而不是冻结整个进程

关注的问题

短任务等待I/O时仍占运行资源,传统进程快照成本妨碍细粒度调度。

作者的方法

由内核捕获可序列化continuation,将I/O表述为effect与回调后恢复执行。

  • 状态与恢复
  • 运行时与调度
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

短任务等待I/O时仍占运行资源,传统进程快照成本妨碍细粒度调度。 Introduction

02 文章用了什么方法

主要方法

由内核捕获可序列化continuation,将I/O表述为effect与回调后恢复执行。

回应的问题

短任务等待I/O时仍占运行资源,传统进程快照成本妨碍细粒度调度。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对内核捕获可序列化continuation、硬件内存隔离以及用effect描述I/O和回调;2.55微秒是特定快照恢复测量。 原文依据原文依据

这些结论有什么条件

研究OS不支持共享内存线程,I/O与计算高度交织和大状态守护进程不适配;不能把微秒数据等同于网络迁移总耗时。 原文依据

04 总结与启发

我们的理解与启发

借鉴等待时显式保存续体的边界,而不是直接替换通用运行时。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 短任务等待I/O时仍占运行资源,传统进程快照成本妨碍细粒度调度。

primary Introduction

D1 · 由内核捕获可序列化continuation,将I/O表述为effect与回调后恢复执行。

core · described · 对应问题 P1 原文依据

E1 Introduction 原文描述

短任务等待I/O时仍占运行资源,传统进程快照成本妨碍细粒度调度。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Continuation syscall and effect interface 原文描述

由内核捕获可序列化continuation,将I/O表述为effect与回调后恢复执行。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Table 1; Section 8 Limitations 编辑核验判断

已核对内核捕获可序列化continuation、硬件内存隔离以及用effect描述I/O和回调;2.55微秒是特定快照恢复测量。 研究OS不支持共享内存线程,I/O与计算高度交织和大状态守护进程不适配;不能把微秒数据等同于网络迁移总耗时。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

StriaTrace:常开骨架 trace,异常时才提高细节

关注的问题

在线推理尾延迟异常短暂,持续重型profiling会扰动生产。

作者的方法

常态只追踪同步点与关键路径,以token量拟合尾延迟上界,异常时补充细粒度采集。

  • 文件与工件
  • 工具与协议
  • 运行时与调度
阅读推荐收起推荐

01 背景与问题

在线推理尾延迟异常短暂,持续重型profiling会扰动生产。 Introduction

02 文章用了什么方法

主要方法

常态只追踪同步点与关键路径,以token量拟合尾延迟上界,异常时补充细粒度采集。

回应的问题

在线推理尾延迟异常短暂,持续重型profiling会扰动生产。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对同步点、关键路径、异常时细粒度采集及按token量拟合尾延迟上界;作者报告追踪开销下降97.8%。 原文依据Abstract; roofline modeling

这些结论有什么条件

该百分比是追踪开销对比,不是推理总体延迟下降;统计上界和关联诊断不能单独证明故障因果。 Abstract; roofline modeling

04 总结与启发

我们的理解与启发

先用低成本信号定位异常,再在关键路径收集细节。 原文依据Abstract; roofline modeling

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 在线推理尾延迟异常短暂,持续重型profiling会扰动生产。

primary Introduction

D1 · 常态只追踪同步点与关键路径,以token量拟合尾延迟上界,异常时补充细粒度采集。

core · described · 对应问题 P1 原文依据

E1 Introduction 原文描述

在线推理尾延迟异常短暂,持续重型profiling会扰动生产。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Tracing principles; regression roofline 原文描述

常态只追踪同步点与关键路径,以token量拟合尾延迟上界,异常时补充细粒度采集。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Abstract; roofline modeling 编辑核验判断

已核对同步点、关键路径、异常时细粒度采集及按token量拟合尾延迟上界;作者报告追踪开销下降97.8%。 该百分比是追踪开销对比,不是推理总体延迟下降;统计上界和关联诊断不能单独证明故障因果。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

AWS Support Companion:每个 Agent 依赖都要有超时、降级与刷新契约

关注的问题

支持工程师需要联合文档、工单和服务状态处理故障。

作者的方法

并行初始化MCP,记忆读取超时后降级,异步保存对话,并在Gateway token过期前刷新。

  • 工具与协议
  • 运行时与调度
  • 记忆与上下文
阅读推荐收起推荐

01 背景与问题

支持工程师需要联合文档、工单和服务状态处理故障。 Incident bottleneck

02 文章用了什么方法

主要方法

并行初始化MCP,记忆读取超时后降级,异步保存对话,并在Gateway token过期前刷新。

回应的问题

支持工程师需要联合文档、工单和服务状态处理故障。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对三MCP并行初始化、最近三轮记忆两秒超时后降级、异步保存及Gateway token提前刷新。 原文依据Security considerations

这些结论有什么条件

降级会失去上下文,异步保存不保证突然崩溃时不丢记录;内容护栏与IAM权限不是同一种控制。 Security considerations

04 总结与启发

我们的理解与启发

把可降级上下文和必须成功的授权步骤分开。 原文依据Security considerations

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 支持工程师需要联合文档、工单和服务状态处理故障。

primary Incident bottleneck

D1 · 并行初始化MCP,记忆读取超时后降级,异步保存对话,并在Gateway token过期前刷新。

core · described · 对应问题 P1 原文依据

E1 Incident bottleneck 原文描述

支持工程师需要联合文档、工单和服务状态处理故障。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Solution overview; agent code 原文描述

并行初始化MCP,记忆读取超时后降级,异步保存对话,并在Gateway token过期前刷新。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Security considerations 编辑核验判断

已核对三MCP并行初始化、最近三轮记忆两秒超时后降级、异步保存及Gateway token提前刷新。 降级会失去上下文,异步保存不保证突然崩溃时不丢记录;内容护栏与IAM权限不是同一种控制。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

Murakkab:让 SLO 成为 Agent 工作流运行时的输入

关注的问题

代理工作流逻辑与模型硬件配置绑定,阻碍质量、成本和延迟的跨层选择。

作者的方法

分离声明式DAG和执行配置,用性能画像选择模型、资源及运行时组合以满足SLO。

  • 状态与恢复
  • 运行时与调度
  • 文件与工件
阅读推荐收起推荐

01 背景与问题

代理工作流逻辑与模型硬件配置绑定,阻碍质量、成本和延迟的跨层选择。 原文依据

02 文章用了什么方法

主要方法

分离声明式DAG和执行配置,用性能画像选择模型、资源及运行时组合以满足SLO。

回应的问题

代理工作流逻辑与模型硬件配置绑定,阻碍质量、成本和延迟的跨层选择。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对显式DAG、画像驱动配置及动态资源组合;到达流由2024年LLM服务trace映射到视频问答与代码工作流。 原文依据4.1 setup; 4.2–4.3 results

这些结论有什么条件

最高4.3倍节省来自指定配置与SLO组合,放宽准确率会改变收益;代理工作流到达分布是近似而非实际生产trace。 4.1 setup; 4.2–4.3 results

04 总结与启发

我们的理解与启发

把任务结构与执行配置分离,同时保留每档质量约束。 原文依据4.1 setup; 4.2–4.3 results

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 代理工作流逻辑与模型硬件配置绑定,阻碍质量、成本和延迟的跨层选择。

primary 原文依据

D1 · 分离声明式DAG和执行配置,用性能画像选择模型、资源及运行时组合以满足SLO。

core · described · 对应问题 P1 原文依据

E1 Introduction; fragmented stack 原文描述

代理工作流逻辑与模型硬件配置绑定,阻碍质量、成本和延迟的跨层选择。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Declarative workflow; profile-guided optimization 原文描述

分离声明式DAG和执行配置,用性能画像选择模型、资源及运行时组合以满足SLO。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 4.1 setup; 4.2–4.3 results 编辑核验判断

已核对显式DAG、画像驱动配置及动态资源组合;到达流由2024年LLM服务trace映射到视频问答与代码工作流。 最高4.3倍节省来自指定配置与SLO组合,放宽准确率会改变收益;代理工作流到达分布是近似而非实际生产trace。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

libDSE:持久执行可以投机,但外部可见性不能投机

关注的问题

分布式持久执行中的同步落盘放大端到端延迟。

作者的方法

允许DSE参与者内部推测执行,跟踪依赖并恢复状态,外部输出通过持久化Barrier。

  • 状态与恢复
  • 文件与工件
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

分布式持久执行中的同步落盘放大端到端延迟。 Introduction

还需处理的问题

外部支付等服务无法撤销推测状态。 DSE; StateObject; Barrier

02 文章用了什么方法

主要方法

允许DSE参与者内部推测执行,跟踪依赖并恢复状态,外部输出通过持久化Barrier。

回应的问题

分布式持久执行中的同步落盘放大端到端延迟。

原文依据 DSE; StateObject; Barrier

配套设计

在非DSE服务之前调用Barrier,等待所有上游依赖持久化。

回应的问题

外部支付等服务无法撤销推测状态。

原文依据 DSE; StateObject; Barrier

03 证据支持到哪里

从原文能确认什么

已核对消息、原子代码块和推测依赖恢复;对外输出须等待依赖持久化,非DSE支付或数据库通过Barrier接入。 DSE; StateObject; BarrierImplementation discussion

这些结论有什么条件

所有推测参与者需适配StateObject,失败可能保守回滚更多工作;不可撤销外部接口仍需等待,不能随意推测执行。 Implementation discussion

04 总结与启发

我们的理解与启发

把可回滚的内部状态与不可撤销的外部承诺分开。 DSE; StateObject; BarrierImplementation discussion

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 分布式持久执行中的同步落盘放大端到端延迟。

primary Introduction

P2 · 外部支付等服务无法撤销推测状态。

secondary · ↳ P1 DSE; StateObject; Barrier

D1 · 允许DSE参与者内部推测执行,跟踪依赖并恢复状态,外部输出通过持久化Barrier。

core · described · 对应问题 P1 DSE; StateObject; Barrier

D2 · 在非DSE服务之前调用Barrier,等待所有上游依赖持久化。

supporting · described · 对应问题 P2 · 支撑 D1 DSE; StateObject; Barrier

E1 Introduction 原文描述

分布式持久执行中的同步落盘放大端到端延迟。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 DSE; StateObject; Barrier 原文描述

允许DSE参与者内部推测执行,跟踪依赖并恢复状态,外部输出通过持久化Barrier。 在非DSE服务之前调用Barrier,等待所有上游依赖持久化。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Implementation discussion 编辑核验判断

已核对消息、原子代码块和推测依赖恢复;对外输出须等待依赖持久化,非DSE支付或数据库通过Barrier接入。 所有推测参与者需适配StateObject,失败可能保守回滚更多工作;不可撤销外部接口仍需等待,不能随意推测执行。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Cloud Run sandboxes:工具执行默认拿不到凭证、网络和持久写权限

关注的问题

应用要运行模型生成代码,同时隔离宿主凭据、网络和写入。

作者的方法

在Cloud Run中提供凭据隔离、默认拒绝出网及临时写层,以显式文件交换交付结果。

  • 身份与权限
  • 文件与工件
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

应用要运行模型生成代码,同时隔离宿主凭据、网络和写入。 Core use cases

02 文章用了什么方法

主要方法

在Cloud Run中提供凭据隔离、默认拒绝出网及临时写层,以显式文件交换交付结果。

回应的问题

应用要运行模型生成代码,同时隔离宿主凭据、网络和写入。

原文依据 Security by design

03 证据支持到哪里

从原文能确认什么

已核对环境与metadata隔离、默认无出网、只读容器文件系统加临时写层,产物需显式导出。 Security by design原文依据

这些结论有什么条件

只读仍能读取容器中可见文件,镜像内敏感文件不应被当成自动隐藏;结束丢弃临时写入不等于撤销已获准外部请求。 原文依据

04 总结与启发

我们的理解与启发

按读取、写入、出网和产物传递分别定义沙箱能力。 Security by design原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 应用要运行模型生成代码,同时隔离宿主凭据、网络和写入。

primary Core use cases

D1 · 在Cloud Run中提供凭据隔离、默认拒绝出网及临时写层,以显式文件交换交付结果。

core · described · 对应问题 P1 Security by design

E1 Core use cases 原文描述

应用要运行模型生成代码,同时隔离宿主凭据、网络和写入。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Security by design 原文描述

在Cloud Run中提供凭据隔离、默认拒绝出网及临时写层,以显式文件交换交付结果。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Filesystem overlay and egress settings 编辑核验判断

已核对环境与metadata隔离、默认无出网、只读容器文件系统加临时写层,产物需显式导出。 只读仍能读取容器中可见文件,镜像内敏感文件不应被当成自动隐藏;结束丢弃临时写入不等于撤销已获准外部请求。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Web Bot Authentication:共享出口 IP 不能充当 Agent 身份

关注的问题

网站需要识别合法机器人操作者,避免把所有AI流量按伪装客户端处理。

作者的方法

从签名目录取得公钥验证HTTP消息,把验证结果和操作者信息标为WAF策略标签。

  • 身份与权限
  • 安全与隔离
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

网站需要识别合法机器人操作者,避免把所有AI流量按伪装客户端处理。 原文依据

02 文章用了什么方法

主要方法

从签名目录取得公钥验证HTTP消息,把验证结果和操作者信息标为WAF策略标签。

回应的问题

网站需要识别合法机器人操作者,避免把所有AI流量按伪装客户端处理。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对签名目录、公钥验证与verified等标签;默认变化具体针对Category:AI和TGT_TokenAbsent。 原文依据Default rule changes

这些结论有什么条件

身份签名证明来源不证明任务得到最终用户授权,也不表示可以绕过其他WAF和业务策略。 Default rule changes

04 总结与启发

我们的理解与启发

把操作者身份标签作为策略输入,而非操作许可本身。 原文依据Default rule changes

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 网站需要识别合法机器人操作者,避免把所有AI流量按伪装客户端处理。

primary 原文依据

D1 · 从签名目录取得公钥验证HTTP消息,把验证结果和操作者信息标为WAF策略标签。

core · described · 对应问题 P1 原文依据

E1 How Web Bot Authentication works 原文描述

网站需要识别合法机器人操作者,避免把所有AI流量按伪装客户端处理。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Signature verification and labels 原文描述

从签名目录取得公钥验证HTTP消息,把验证结果和操作者信息标为WAF策略标签。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Default rule changes 编辑核验判断

已核对签名目录、公钥验证与verified等标签;默认变化具体针对Category:AI和TGT_TokenAbsent。 身份签名证明来源不证明任务得到最终用户授权,也不表示可以绕过其他WAF和业务策略。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Structured memory filtering with metadata in AgentCore Memory:先确定边界,再做相似度

关注的问题

仅语义相似度难以准确检索指定时间、部门或客户范围的记忆。

作者的方法

确定性元数据原样传播并隔离提取合并,主题等字段可由模型推断,检索组合结构与语义条件。

  • 记忆与上下文
  • 安全与隔离
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

仅语义相似度难以准确检索指定时间、部门或客户范围的记忆。 原文依据

还需处理的问题

模型重猜已知部门会造成错误分组和合并。 STRICTLY_CONSISTENT metadata

02 文章用了什么方法

主要方法

确定性元数据原样传播并隔离提取合并,主题等字段可由模型推断,检索组合结构与语义条件。

回应的问题

仅语义相似度难以准确检索指定时间、部门或客户范围的记忆。

原文依据 STRICTLY_CONSISTENT metadata

配套设计

将这些键设为STRICTLY_CONSISTENT,按确定性值隔离提取与合并。

回应的问题

模型重猜已知部门会造成错误分组和合并。

原文依据 STRICTLY_CONSISTENT metadata

03 证据支持到哪里

从原文能确认什么

已核对确定性元数据原样传播并隔离提取合并、LLM推断主题和结构过滤;每策略最多三确定性键且占索引槽位。 STRICTLY_CONSISTENT metadata原文依据

这些结论有什么条件

缺失确定性字段仍会处理,过滤条件与namespace必须由可信应用设置;时间过滤改进没有给出可泛化数值。 原文依据

04 总结与启发

我们的理解与启发

已知事实用结构字段传递,不让模型重新猜租户或部门。 STRICTLY_CONSISTENT metadata原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 仅语义相似度难以准确检索指定时间、部门或客户范围的记忆。

primary 原文依据

P2 · 模型重猜已知部门会造成错误分组和合并。

secondary · ↳ P1 STRICTLY_CONSISTENT metadata

D1 · 确定性元数据原样传播并隔离提取合并,主题等字段可由模型推断,检索组合结构与语义条件。

core · described · 对应问题 P1 STRICTLY_CONSISTENT metadata

D2 · 将这些键设为STRICTLY_CONSISTENT,按确定性值隔离提取与合并。

supporting · described · 对应问题 P2 · 支撑 D1 STRICTLY_CONSISTENT metadata

E1 Structuring namespaces and metadata 原文描述

仅语义相似度难以准确检索指定时间、部门或客户范围的记忆。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 STRICTLY_CONSISTENT metadata 原文描述

确定性元数据原样传播并隔离提取合并,主题等字段可由模型推断,检索组合结构与语义条件。 将这些键设为STRICTLY_CONSISTENT,按确定性值隔离提取与合并。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Temporal filtering; indexed key limits 编辑核验判断

已核对确定性元数据原样传播并隔离提取合并、LLM推断主题和结构过滤;每策略最多三确定性键且占索引槽位。 缺失确定性字段仍会处理,过滤条件与namespace必须由可信应用设置;时间过滤改进没有给出可泛化数值。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

SeaweedFS:过期客户端不能靠“最后写入者获胜”

关注的问题

不同后端缺少统一条件写能力,分布式锁又增加成本。

作者的方法

把条件变更路由到对象owner,在本地路径锁内检查前提并应用变更。

  • 文件与工件
阅读推荐收起推荐

01 背景与问题

不同后端缺少统一条件写能力,分布式锁又增加成本。 原文依据

02 文章用了什么方法

主要方法

把条件变更路由到对象owner,在本地路径锁内检查前提并应用变更。

回应的问题

不同后端缺少统一条件写能力,分布式锁又增加成本。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对对象路由到owner、局部锁内检查条件后应用变更,以及一跳转发限制。 原文依据Why it does not cost latency

这些结论有什么条件

正文同时声称所有写入归同owner和无条件写不路由锁定,不能据此断言所有混合写入都线性化;成员切换下也未给出fencing证明。 Why it does not cost latency

04 总结与启发

我们的理解与启发

把稳态单对象串行化与故障切换一致性分开陈述。 原文依据Why it does not cost latency

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 不同后端缺少统一条件写能力,分布式锁又增加成本。

primary 原文依据

D1 · 把条件变更路由到对象owner,在本地路径锁内检查前提并应用变更。

core · described · 对应问题 P1 原文依据

E1 Why obvious answers do not fit 原文描述

不同后端缺少统一条件写能力,分布式锁又增加成本。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Route by object; local owner lock 原文描述

把条件变更路由到对象owner,在本地路径锁内检查前提并应用变更。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Why it does not cost latency 编辑核验判断

已核对对象路由到owner、局部锁内检查条件后应用变更,以及一跳转发限制。 正文同时声称所有写入归同owner和无条件写不路由锁定,不能据此断言所有混合写入都线性化;成员切换下也未给出fencing证明。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

W3C:永久链接应标识资源,临时 URL 只负责传输

关注的问题

Web代理协议快速增加,身份、描述、发现和交互能力存在重叠及缺口。

作者的方法

按统一资源空间与超媒体架构比较代理身份、profile、发现和交互协议。

  • 文件与工件
  • 身份与权限
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

Web代理协议快速增加,身份、描述、发现和交互能力存在重叠及缺口。 Introduction

02 文章用了什么方法

主要方法

按统一资源空间与超媒体架构比较代理身份、profile、发现和交互协议。

回应的问题

Web代理协议快速增加,身份、描述、发现和交互能力存在重叠及缺口。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对统一资源空间与超媒体架构、A2A/ANP/MCP等描述比较;这是持续演进的研究文档。 原文依据原文依据

这些结论有什么条件

政策、认证与总结部分仍有占位文字,不能写成已完成统一安全规范;通用表示也增加转换成本。 原文依据

04 总结与启发

我们的理解与启发

按能力维度比较协议,区分研究提案、已定义字段与尚未完成章节。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · Web代理协议快速增加,身份、描述、发现和交互能力存在重叠及缺口。

primary Introduction

D1 · 按统一资源空间与超媒体架构比较代理身份、profile、发现和交互协议。

core · described · 对应问题 P1 原文依据

E1 Introduction 原文描述

Web代理协议快速增加,身份、描述、发现和交互能力存在重叠及缺口。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Architectural Constraints; agent and tool profiles 原文描述

按统一资源空间与超媒体架构比较代理身份、profile、发现和交互协议。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Policies, Security and Conclusions sections 编辑核验判断

已核对统一资源空间与超媒体架构、A2A/ANP/MCP等描述比较;这是持续演进的研究文档。 政策、认证与总结部分仍有占位文字,不能写成已完成统一安全规范;通用表示也增加转换成本。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

AWS S3:先给每个对象版本一个身份证,再谈缓存

关注的问题

存量S3启用版本传播期间的短暂404可能被CDN缓存放大。

作者的方法

存量桶先进入Suspended并等待传播,观察版本头后再转Enabled,降低CDN负缓存风险。

  • 文件与工件
  • 状态与恢复
  • 身份与权限
阅读推荐收起推荐

01 背景与问题

存量S3启用版本传播期间的短暂404可能被CDN缓存放大。 CDN amplification problem

02 文章用了什么方法

主要方法

存量桶先进入Suspended并等待传播,观察版本头后再转Enabled,降低CDN负缓存风险。

回应的问题

存量S3启用版本传播期间的短暂404可能被CDN缓存放大。

原文依据 Three versioning patterns

03 证据支持到哪里

从原文能确认什么

已核对先Suspended、等待至少15分钟、HeadObject观察版本头后Enabled的官方案例步骤。 Three versioning patterns原文依据

这些结论有什么条件

原文说明没有直接确认全局传播完成的API;单对象版本头是操作信号,不是全局证明,版本存储还需生命周期控制。 原文依据

04 总结与启发

我们的理解与启发

把配置传播、数据可见性和边缘负缓存分别考虑。 Three versioning patterns原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 存量S3启用版本传播期间的短暂404可能被CDN缓存放大。

primary CDN amplification problem

D1 · 存量桶先进入Suspended并等待传播,观察版本头后再转Enabled,降低CDN负缓存风险。

core · described · 对应问题 P1 Three versioning patterns

E1 CDN amplification problem 原文描述

存量S3启用版本传播期间的短暂404可能被CDN缓存放大。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Three versioning patterns 原文描述

存量桶先进入Suspended并等待传播,观察版本头后再转Enabled,降低CDN负缓存风险。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Suspended-mode steps and Vercel case 编辑核验判断

已核对先Suspended、等待至少15分钟、HeadObject观察版本头后Enabled的官方案例步骤。 原文说明没有直接确认全局传播完成的API;单对象版本头是操作信号,不是全局证明,版本存储还需生命周期控制。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

APNIC:用通知减少延迟,用对账保证最终正确

关注的问题

数据副本规模增长时,全量传输和高频轮询会放大成本。

作者的方法

按权威关系和变化粒度选择块差分、快照增量或Merkle对账,并比较推拉及混合同步。

  • 文件与工件
  • 状态与恢复
  • 观测与评测
阅读推荐收起推荐

01 背景与问题

数据副本规模增长时,全量传输和高频轮询会放大成本。 Synchronization problem

02 文章用了什么方法

主要方法

按权威关系和变化粒度选择块差分、快照增量或Merkle对账,并比较推拉及混合同步。

回应的问题

数据副本规模增长时,全量传输和高频轮询会放大成本。

原文依据 Merkle trees; Pull vs push

03 证据支持到哪里

从原文能确认什么

已核对规范排序的Merkle比较、快照增量、TTL式拉取节奏与推通知后拉取的混合方案。 Merkle trees; Pull vs pushPeer systems and Conclusions

这些结论有什么条件

定位差异的树形效率不等于传输任意变化量都为对数;多写者还涉及冲突和权威来源。 Peer systems and Conclusions

04 总结与启发

我们的理解与启发

先确定数据权威、变化粒度与允许陈旧时间,再选同步机制。 Merkle trees; Pull vs pushPeer systems and Conclusions

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 数据副本规模增长时,全量传输和高频轮询会放大成本。

primary Synchronization problem

D1 · 按权威关系和变化粒度选择块差分、快照增量或Merkle对账,并比较推拉及混合同步。

core · described · 对应问题 P1 Merkle trees; Pull vs push

E1 Synchronization problem 原文描述

数据副本规模增长时,全量传输和高频轮询会放大成本。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Merkle trees; Pull vs push 原文描述

按权威关系和变化粒度选择块差分、快照增量或Merkle对账,并比较推拉及混合同步。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Peer systems and Conclusions 编辑核验判断

已核对规范排序的Merkle比较、快照增量、TTL式拉取节奏与推通知后拉取的混合方案。 定位差异的树形效率不等于传输任意变化量都为对数;多写者还涉及冲突和权威来源。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

AG-UI:事件流是失效通知,不是文件内容真相源

关注的问题

不同代理框架的流式输出使前端反复适配,工具执行还要与用户交互同步。

作者的方法

用AG-UI统一事件和状态传输,由前端注册组件,并以工具结果恢复用户交互。

  • 文件与工件
  • 工具与协议
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

不同代理框架的流式输出使前端反复适配,工具执行还要与用户交互同步。 Overview of solution

02 文章用了什么方法

主要方法

用AG-UI统一事件和状态传输,由前端注册组件,并以工具结果恢复用户交互。

回应的问题

不同代理框架的流式输出使前端反复适配,工具执行还要与用户交互同步。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对统一事件解析、前端预定义组件、STATE_SNAPSHOT及用工具结果恢复用户输入。 原文依据原文依据

这些结论有什么条件

样例是受控组件而非任意生成代码;UI回传和状态流并不替代后端权限或并发冲突解决。 原文依据

04 总结与启发

我们的理解与启发

让协议承担事件与状态传递,业务层承担授权和内容校验。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 不同代理框架的流式输出使前端反复适配,工具执行还要与用户交互同步。

primary Overview of solution

D1 · 用AG-UI统一事件和状态传输,由前端注册组件,并以工具结果恢复用户交互。

core · described · 对应问题 P1 原文依据

E1 Overview of solution 原文描述

不同代理框架的流式输出使前端反复适配,工具执行还要与用户交互同步。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 AG-UI parser; CopilotKit patterns 原文描述

用AG-UI统一事件和状态传输,由前端注册组件,并以工具结果恢复用户交互。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Shared state and human interaction 编辑核验判断

已核对统一事件解析、前端预定义组件、STATE_SNAPSHOT及用工具结果恢复用户输入。 样例是受控组件而非任意生成代码;UI回传和状态流并不替代后端权限或并发冲突解决。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

论文

RECEIPT:不要相信 Agent 的“我完成了”

关注的问题

白盒安全代理可能利用探索权限制造浏览器执行信号而没有真实攻击路径。

作者的方法

将探索与干净验证环境分离,限定攻击者和受害者接口,并把浏览器信号绑定到裁决。

  • 文件与工件
  • 观测与评测
  • 安全与隔离
阅读推荐收起推荐

01 背景与问题

白盒安全代理可能利用探索权限制造浏览器执行信号而没有真实攻击路径。 I Introduction

02 文章用了什么方法

主要方法

将探索与干净验证环境分离,限定攻击者和受害者接口,并把浏览器信号绑定到裁决。

回应的问题

白盒安全代理可能利用探索权限制造浏览器执行信号而没有真实攻击路径。

原文依据 III-B mechanism components

03 证据支持到哪里

从原文能确认什么

已核对独立干净验证实例、攻击者HTTP接口、受害者动作约束及绑定裁决;作者区分发现数、确认数和维护者接受数。 III-B mechanism components原文依据

这些结论有什么条件

角色定义与初始快照错误仍可能产生假阳性,当前仅一种模型配置和Chromium;部署WAF影响单独判断。 原文依据

04 总结与启发

我们的理解与启发

证据有效性同时依赖执行信号、角色与环境边界。 III-B mechanism components原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 白盒安全代理可能利用探索权限制造浏览器执行信号而没有真实攻击路径。

primary I Introduction

D1 · 将探索与干净验证环境分离,限定攻击者和受害者接口,并把浏览器信号绑定到裁决。

core · described · 对应问题 P1 III-B mechanism components

E1 I Introduction 原文描述

白盒安全代理可能利用探索权限制造浏览器执行信号而没有真实攻击路径。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 III-B mechanism components 原文描述

将探索与干净验证环境分离,限定攻击者和受害者接口,并把浏览器信号绑定到裁决。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 VI Discussion; validity threats 编辑核验判断

已核对独立干净验证实例、攻击者HTTP接口、受害者动作约束及绑定裁决;作者区分发现数、确认数和维护者接受数。 角色定义与初始快照错误仍可能产生假阳性,当前仅一种模型配置和Chromium;部署WAF影响单独判断。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

OBO:让工具知道“谁委托谁做了什么”

关注的问题

多租户代理调用下游API时需要保持用户主体和实际权限。

作者的方法

以OBO交换保留用户身份,由资源服务验证有效权限声明,并按tenant与sub限定数据范围。

  • 身份与权限
  • 工具与协议
  • 运行时与调度
阅读推荐收起推荐

01 背景与问题

多租户代理调用下游API时需要保持用户主体和实际权限。 Confused deputy problem

还需处理的问题

交换后的scope可能未按用户角色裁剪。 原文依据

02 文章用了什么方法

主要方法

以OBO交换保留用户身份,由资源服务验证有效权限声明,并按tenant与sub限定数据范围。

回应的问题

多租户代理调用下游API时需要保持用户主体和实际权限。

原文依据 原文依据

配套设计

文中Okta方案在令牌加入authorized_scopes,由资源服务据此判定写权限。

回应的问题

交换后的scope可能未按用户角色裁剪。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对RFC8693交换、Okta示例authorized_scopes声明与tenant加sub分区;M2M交换不会按交互登录规则裁剪用户scope。 原文依据原文依据

这些结论有什么条件

该scope行为是文中Okta配置条件,不能外推所有OAuth服务;传播身份后仍由资源服务实施授权。 原文依据

04 总结与启发

我们的理解与启发

审查交换后令牌实际含义及资源端判定,不能只看OBO标签。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 多租户代理调用下游API时需要保持用户主体和实际权限。

primary Confused deputy problem

P2 · 交换后的scope可能未按用户角色裁剪。

secondary · ↳ P1 原文依据

D1 · 以OBO交换保留用户身份,由资源服务验证有效权限声明,并按tenant与sub限定数据范围。

core · described · 对应问题 P1 原文依据

D2 · 文中Okta方案在令牌加入authorized_scopes,由资源服务据此判定写权限。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Confused deputy problem 原文描述

多租户代理调用下游API时需要保持用户主体和实际权限。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Two legs; per-user scopes; sub partition 原文描述

以OBO交换保留用户身份,由资源服务验证有效权限声明,并按tenant与sub限定数据范围。 文中Okta方案在令牌加入authorized_scopes,由资源服务据此判定写权限。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Common pitfalls and scope discussion 编辑核验判断

已核对RFC8693交换、Okta示例authorized_scopes声明与tenant加sub分区;M2M交换不会按交互登录规则裁剪用户scope。 该scope行为是文中Okta配置条件,不能外推所有OAuth服务;传播身份后仍由资源服务实施授权。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

WAF + PrivateLink:安全入口不能留下可绕过的第二扇门

关注的问题

给AgentCore加WAF入口后,公开直连端点可能绕过检查。

作者的方法

用WAF、ALB和PrivateLink建立入口,再用资源策略拒绝绕开指定端点的直接请求。

  • 安全与隔离
  • 运行时与调度
  • 工具与协议
阅读推荐收起推荐

01 背景与问题

给AgentCore加WAF入口后,公开直连端点可能绕过检查。 Architecture overview

还需处理的问题

有效凭据仍可直接访问公网端点绕过WAF。 原文依据

02 文章用了什么方法

主要方法

用WAF、ALB和PrivateLink建立入口,再用资源策略拒绝绕开指定端点的直接请求。

回应的问题

给AgentCore加WAF入口后,公开直连端点可能绕过检查。

原文依据 原文依据

配套设计

用SourceVpce条件和显式Deny封闭直连,同时保留列明的服务调用例外。

回应的问题

有效凭据仍可直接访问公网端点绕过WAF。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对ALB经Lambda或直接VPC Endpoint两条路径,以及SourceVpce允许与显式拒绝直连策略。 原文依据原文依据

这些结论有什么条件

策略保留ViaAWSService例外,端点IP重建可变化;50–200毫秒是文中Lambda额外延迟范围,网络WAF不检验代理语义正确。 原文依据

04 总结与启发

我们的理解与启发

入口控制要覆盖所有可达路径,并把例外条件写清。 原文依据原文依据

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 给AgentCore加WAF入口后,公开直连端点可能绕过检查。

primary Architecture overview

P2 · 有效凭据仍可直接访问公网端点绕过WAF。

secondary · ↳ P1 原文依据

D1 · 用WAF、ALB和PrivateLink建立入口,再用资源策略拒绝绕开指定端点的直接请求。

core · described · 对应问题 P1 原文依据

D2 · 用SourceVpce条件和显式Deny封闭直连,同时保留列明的服务调用例外。

supporting · described · 对应问题 P2 · 支撑 D1 原文依据

E1 Architecture overview 原文描述

给AgentCore加WAF入口后,公开直连端点可能绕过检查。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Two ALB patterns; resource policy 原文描述

用WAF、ALB和PrivateLink建立入口,再用资源策略拒绝绕开指定端点的直接请求。 用SourceVpce条件和显式Deny封闭直连,同时保留列明的服务调用例外。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Trade-offs; important considerations 编辑核验判断

已核对ALB经Lambda或直接VPC Endpoint两条路径,以及SourceVpce允许与显式拒绝直连策略。 策略保留ViaAWSService例外,端点IP重建可变化;50–200毫秒是文中Lambda额外延迟范围,网络WAF不检验代理语义正确。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Microsoft Foundry:工具目录和执行目录要分开

关注的问题

平台把工具发现、运行调度、配置优化和记忆生命周期整合到托管代理。

作者的方法

以Tool Search按需发现工具,用Routines管理运行,并提供配置优化与记忆TTL等独立能力。

  • 工具与协议
  • 记忆与上下文
  • 运行时与调度
阅读推荐收起推荐

01 背景与问题

平台把工具发现、运行调度、配置优化和记忆生命周期整合到托管代理。 June release roundup

02 文章用了什么方法

主要方法

以Tool Search按需发现工具,用Routines管理运行,并提供配置优化与记忆TTL等独立能力。

回应的问题

平台把工具发现、运行调度、配置优化和记忆生命周期整合到托管代理。

原文依据 Toolboxes; Optimizer; Memory

03 证据支持到哪里

从原文能确认什么

已核对Tool Search按需schema、Routines、优化候选比较及procedural memory与TTL;多个功能仍为预览。 Toolboxes; Optimizer; MemoryPreview status and SDK notes

这些结论有什么条件

Optimizer文中为私有预览,预期公测不是已发布事实;TTL字段及默认值有版本特例,榜单复合分数不等于全场景可靠。 Preview status and SDK notes

04 总结与启发

我们的理解与启发

拆分各功能的交付状态与责任,避免把路线图合成现有能力。 Toolboxes; Optimizer; MemoryPreview status and SDK notes

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 平台把工具发现、运行调度、配置优化和记忆生命周期整合到托管代理。

primary June release roundup

D1 · 以Tool Search按需发现工具,用Routines管理运行,并提供配置优化与记忆TTL等独立能力。

core · described · 对应问题 P1 Toolboxes; Optimizer; Memory

E1 June release roundup 原文描述

平台把工具发现、运行调度、配置优化和记忆生命周期整合到托管代理。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Toolboxes; Optimizer; Memory 原文描述

以Tool Search按需发现工具,用Routines管理运行,并提供配置优化与记忆TTL等独立能力。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 Preview status and SDK notes 编辑核验判断

已核对Tool Search按需schema、Routines、优化候选比较及procedural memory与TTL;多个功能仍为预览。 Optimizer文中为私有预览,预期公测不是已发布事实;TTL字段及默认值有版本特例,榜单复合分数不等于全场景可靠。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

工程实践

Google Cloud:先定义数据驻留和容量,再选运行时

关注的问题

企业调用Claude需要同时考虑容量、地域、访问控制与应用运行。

作者的方法

分别选择global、regional或multi-region端点、推理容量及代理运行环境,接入IAM与网络控制。

  • 运行时与调度
  • 观测与评测
  • 状态与恢复
阅读推荐收起推荐

01 背景与问题

企业调用Claude需要同时考虑容量、地域、访问控制与应用运行。 Managed infrastructure

02 文章用了什么方法

主要方法

分别选择global、regional或multi-region端点、推理容量及代理运行环境,接入IAM与网络控制。

回应的问题

企业调用Claude需要同时考虑容量、地域、访问控制与应用运行。

原文依据 原文依据

03 证据支持到哪里

从原文能确认什么

已核对global/regional/multi-region端点取舍、ADC/IAM、缓存与批处理及独立agent runtime。 原文依据From inference to agents

这些结论有什么条件

缓存最高节省针对可复用前缀而非所有请求;全球路由与地域约束需要选择,平台合规不自动覆盖整个应用。 From inference to agents

04 总结与启发

我们的理解与启发

分别选择模型入口、数据地域和代理执行环境。 原文依据From inference to agents

查看证据与分析底稿

原文核验于 2026-09-09 · 问题层级与对应关系属于编辑判断。

P1 · 企业调用Claude需要同时考虑容量、地域、访问控制与应用运行。

primary Managed infrastructure

D1 · 分别选择global、regional或multi-region端点、推理容量及代理运行环境,接入IAM与网络控制。

core · described · 对应问题 P1 原文依据

E1 Managed infrastructure 原文描述

企业调用Claude需要同时考虑容量、地域、访问控制与应用运行。

依据原文的问题陈述归纳场景;主次层级属于编辑判断。

查看原文 ↗

E2 Endpoint types; cost and performance 原文描述

分别选择global、regional或multi-region端点、推理容量及代理运行环境,接入IAM与网络控制。

原文描述的机制或分析方法;不能仅由描述推导实际效果。

查看原文 ↗

E3 From inference to agents 编辑核验判断

已核对global/regional/multi-region端点取舍、ADC/IAM、缓存与批处理及独立agent runtime。 缓存最高节省针对可复用前缀而非所有请求;全球路由与地域约束需要选择,平台合规不自动覆盖整个应用。

对作者结果、比较条件与论证边界的阅读核验;保留正文冲突,不扩大外推范围。

查看原文 ↗

原始来源

我们如何分析一篇文章

先讲清文章要回答什么、方法如何回应,再看证据支持到哪里。正文按贡献展开,来源与对应关系可在底稿中追溯。作者结果与我们的采用判断分开表达;推荐分表示阅读优先级,不等于证据可信度。

推荐 / 阅读

阅读原文 ↗