Agent 上下文治理：从记忆、证据到行动权限的工程控制

执行摘要

“上下文治理”（Context Governance）不是简单地给 Agent 更多上下文，而是决定：

• 什么上下文可以进入当前推理；
• 以什么身份、权重和时效进入；
• 能授权什么动作；
• 什么时候失效；
• 如何审计、回滚和隔离。

如果不治理，LLM Agent 最常见的失败并不是“不会推理”，而是把错误的、过期的、不完整的、失去来源的、被错误升权的上下文，当成了行动依据。

2026 年几篇相关论文和多篇工程复盘共同指向同一个结论：Agent 可靠性的中心问题，正在从“模型够不够聪明”转向“上下文是否被正确接纳、解释、验证、写回和交接”。

EnvTrustBench 的实验显示，在 14 个 agent–LLM 组合、3,850 次有效运行中，总环境误扎根率（Environmental Misgrounding Rate, EMR）达到 83.3%；即使最佳组合的平均 EMR 仍有 55.3%。这说明“会用工具”不等于“会正确相信工具返回的证据”。[1]

另一个关键风险是记忆巩固本身会腐蚀证据。“Useful Memories Become Faulty When Continuously Updated by LLMs” 发现，把成功轨迹持续压缩为抽象记忆并反复重写，性能会先升后降，甚至低于无记忆基线。它说明，长期 Agent 的问题不是“记忆不够多”，而是“错误抽象被持续固化”。[2]

真实工程事故也显示，生产里最危险的不是单次回答错误，而是“错误上下文 + 自主写入”。公开案例包括 Replit / SaaStr 数据库删除事故、Claude Code / Skills 社区中的错误 skill 固化案例、以及工程文章中记录的循环提交、范围扩张、skill 污染、运行时状态缺失等问题。[5][6][8][9][10][12][16]

因此，本报告的核心建议是：把 Context Governance 落成一套可执行的工程控制层，而不是只靠 prompt 或“提醒模型”。最低可行方案包括：

• 为每个上下文对象打元数据；
• 把“当前时间”等易失变量改为运行时求值；
• 把写操作与上下文完整性、证据覆盖率绑定；
• 把长期记忆拆成 episodic store 与 abstract store；
• 对记忆整合设置 Consolidation Gate；
• 对所有高风险写动作设置 Write Harness；
• 为提醒、cron、健康检查建立 P0–P3 注意力策略；
• 为 skills 建立注册表、TTL、版本和失效管理；
• 为每次行动生成可回放 trace、claim table 与 provenance 绑定。

这些控制不会让 Agent 完美，但会把“错一次就扩散”的系统，变成“错了也能及时止损、定位和回滚”的系统。

推荐控制对照表

一、上下文污染的分类与机制

上下文污染不是单点问题，而是一组会在不同阶段发生、彼此放大的失真机制。它们共同作用后，会把一个本来只属于“提示噪声”的问题，升级成“错误动作授权”的问题。

1. 核心定义

上下文治理可以定义为：

对 Agent 在“观察 → 接纳 → 解释 → 计划 → 执行 → 写回 → 交接”全链路中所有上下文对象的来源、权威、时效、适用域、完整性、写权限与可审计性进行制度化约束的工程实践。

与这个定义对应，上下文对象不应再被当作一段无差别文本，而应视为具备状态的实体。它可以是用户输入、系统提示、工具输出、环境观察、记忆条目、skill、handoff 摘要、外部文件片段、审计结论或运行时变量解析结果。

2. 污染类型总表

3. 这些污染如何发生

权威污染

权威污染最常见的来源，是把不同角色的文本拼在一起，而不显式标注“谁有决策权”。

EnvTrustBench 对公开可见 scaffold 的检查表明，多数开源 scaffold 对执行权限有硬门，但几乎没有对运行时反馈、证据验证、来源标注给出可执行的 gating。换句话说，它们更善于阻止“命令执行”，却不善于阻止“误信某条证据后执行命令”。[1]

时间污染

时间污染来自把运行时瞬时值放进长期上下文或摘要里。比如，如果让 Agent 直接把“当前时间”当作自然语言事实记住，它往往会在后续会话甚至第二天继续沿用旧值。

正确做法是让它通过工具在动作时刻取值，而不是在推理时刻固化。例如：

node -e 'console.log(new Date().toISOString())'

这个问题本质上不是“时间不会算”，而是把 runtime variable 误持久化成 knowledge。

完整性污染

完整性污染来自“证据覆盖率”和“动作范围”不匹配。

典型例子是“部分读取 + 整文件写回”：Agent 只看到局部内容，却获得了覆盖整个对象的写权限。结果是，未读取部分可能被截断、丢失或重写。

类似问题也存在于生产环境中。Agent 在本地看似“代码能跑”，但如果缺少真实 env vars、真实数据库 schema、上游 auth headers、队列 topic 等隐藏运行时上下文，它对生产系统的修改实际上只是“有理有据的猜测”。[18]

来源污染

来源污染通常发生在两种场景：

1. 检索失败后自行补全；
2. 多轮总结后把“推断”升级成“引用”。

如果系统不能说明哪一句来自文档、哪一句是模型推断、哪一句只是格式补全，后续的每一次总结和引用都会继续扩大污染。

工程上更实用的理解是：结论与证据 span 脱钩。

交接污染

交接污染常被低估。售后、产品、工程、Agent 之间传递的往往不是结构化交接包，而是聊天记录、截图、长文档、半成品 PRD、临时结论。

这些材料一旦直接拼进下游 prompt，就会把上游的误解、遗漏、语气、权威错觉一起传下去。

Skill 污染

Anthropic 官方将 skills 定义为按需动态加载的 instructions、scripts、resources，并强调要从可信源安装、审计 skill 内代码和说明，同时建议按任务结构拆分，避免一个 SKILL.md 过大。[6]

但当 skills 数量变大后，问题会从“有没有 skill”变成“哪个 skill 应被激活，何时失效，会不会冲突”。工程文章记录，当 skills 超过 20–30 个后，选择和失效治理会成为主要瓶颈。[12]

注意力策略污染

注意力策略污染发生在“为了减少打扰”而破坏告警分级时。

一个真实故障是：原目标是清理无意义实时化脚本、减轻注意力负担，结果 Agent 把所有应该发给人的 cron 任务也改成 silent。这不是简单执行错误，而是把注意力路由策略当作可随意优化的代码对象，却没有理解 P0/P1/P2/P3 的组织含义。

证据误扎根

EnvTrustBench 将这类问题定义为 Evidence-Grounding Defect：Agent 把文件、网页、API 响应、日志、下载脚本等环境证据当成地面真相，而不是需要核验的观察。[1]

研究者检查了几个开源 scaffold 后发现：虽然它们普遍有执行权限控制，但没有一个对 runtime feedback、evidence verification、evidence provenance 提供可执行硬门。也就是说，现有脚手架治理的是“执行权限”，不是“证据可信度”。[1]

记忆巩固侵蚀

Faulty Memory 论文证明，如果把“从过去经验抽象出 lesson”做成默认、频繁、自动的行为，Agent 的长期记忆会逐步从可用知识变成误导性知识。[2]

对上下文治理的含义是：

不要把 consolidation 当成自然副产品，而要把它当成高风险写操作。

二、证据、案例与教训

1. 公开案例与时间线

这些案例的共同点不是“模型犯了低级错误”，而是系统把低质量上下文接纳进来，并赋予了过高的行动权。

2. 本次对话中的私有个案

以下故障来自本次对话中的用户自述，不是公开资料，也未独立核验。但它们对 Context Governance 很有价值，因为它们补足了公开案例里常被忽略的组织内部微故障。

当前时间被当作可持久知识

这证明 temporal pollution 不需要复杂 memory 系统才会发生。只要 Agent 把 runtime value 当作普通事实保存，就会把“当时”误当成“恒定”。

部分读取 + 整文件写回

这导致未纳入 git 的新笔记被截断。它是完整性污染的典型例子：写权限大于证据覆盖。

治理重点不在“模型更仔细”，而在：

没有完整读取和校验之前，不得取得整对象写权限。

文档引用编造

这说明 provenance 污染往往发生在系统试图维持“回答看起来完整”时。它宁愿生成一个像真的标题、百分比、链接，也不愿明确说“没有在文档里找到”。

cron 被统一静音

这说明注意力策略本身也会被污染。系统优化了“噪声量”，却破坏了“告警优先级”。

如果把这些内部故障与公开案例放在一起，可以看到一条清晰主线：

上下文污染的危害不从“错一句话”开始，而从“错对象进入高权决策面”开始。

三、论文证据与现有系统评估

1. 关键论文与实验结果

这四篇论文连起来看，回答的是同一个问题：

Agent 并不缺“生成动作”的能力，缺的是让动作建立在正确上下文上的制度。

EnvTrustBench 告诉我们证据会被误信；Faulty Memory 告诉我们长期记忆会被误巩固；SREGym 告诉我们真实生产中的环境噪声和动态性会放大这些问题；Beyond the Black Box 告诉我们，如果不能在执行前观察工具决策信号，很多错误只能在 damage 之后看见。

2. 对现有 scaffold、memory system 与官方安全机制的评价

现有 agent scaffold 的优点，是大多已经意识到“执行权限必须受控”。Gemini CLI、Codex、OpenClaw、OpenCode 等系统在 execution authority 上有一定硬门；Anthropic 也在 Claude Code 中强调权限确认、sandbox、auto mode 与 checkpoints。[1][5][7]

但它们共同的薄弱点是：

它们控制了“能不能执行”，却没有系统性控制“该不该相信当前上下文来执行”。

Claude Code 的 auto mode 目标，是减少 permission prompt 带来的 approval fatigue；checkpoints 让长任务更可回退。但 checkpoints 只覆盖 Claude 的代码编辑，不覆盖用户编辑或 bash 命令，因此不能替代真正的 Write Harness。[5][7]

在 memory system 上，很多方案默认将经验写入 text memory bank 并持续更新。Faulty Memory 的结果表明，只要 consolidation 频繁、跨家族、无评估、无 gating，就会磨掉原始 episode 中仍然有用的条件、边界和失败教训。[2]

在 skill 系统上，Anthropic 官方强调按需加载、结构拆分、可信源和审计；但一旦进入大规模，主要问题会变成 skill routing、staleness 和冲突治理。[6][12]

四、可执行的上下文治理框架

1. 上下文对象元数据模型

最基本的改变，是把所有上下文对象化。一个最小可行 schema：

{
  "id": "ctx_...",
  "source": "user|system|tool|memory|skill|handoff|file|web|runtime",
  "authority": "system|policy|user|verified_tool|unverified_tool|memory|skill|external",
  "freshness": {
    "observed_at": "2026-05-18T12:34:56Z",
    "valid_until": "2026-05-18T12:35:56Z"
  },
  "scope": ["repo:foo", "file:src/a.ts", "service:billing", "session:123"],
  "coverage": {
    "objects_required": 5,
    "objects_observed": 4,
    "coverage_ratio": 0.8
  },
  "ttl": 60,
  "allowed_action_level": "L1",
  "provenance_span": [
    {
      "artifact_id": "tool_stdout_7",
      "start": 120,
      "end": 188
    }
  ],
  "hash": "sha256:...",
  "verified": false,
  "runtime_bound": false
}

其中以下字段应视为硬字段：

• source
• authority
• freshness
• scope
• coverage
• ttl
• allowed_action_level
• provenance_span
• hash

建议再加四个字段：

• derived_from
• conflicts_with
• verified_by
• runtime_bound

其中 runtime_bound=true 专门用于“当前时间、当前 git 分支、当前 Kubernetes 上下文、当前 schema 版本”这类绝不应持久化为静态知识的对象。

2. 从观察到审计的治理流

Observation
  ↓
Admission Gate
  - source?
  - authority?
  - freshness?
  - scope?
  ↓
Interpretation
  - claims
  - constraints
  - candidates
  ↓
Verification Gate
  - evidence span?
  - coverage?
  - live verification?
  ↓
Plan
  - actions
  - cited claims
  ↓
Action Gate
  - allowed_action_level?
  - human review?
  - sandbox / dry-run?
  ↓
Write / Execute
  ↓
Write Gate
  - atomic write?
  - backup?
  - diff?
  - invariants?
  ↓
Audit
  - trace
  - claim table
  - provenance binding

这个流程把模型思考前后拆成多个有界阶段：

• Admission Gate：决定对象能否进入上下文。
• Verification Gate：决定 claim 是否能升权为行动依据。
• Action Gate：决定该依据是否足以授权动作。
• Write Gate：确保即使动作被授权，写路径仍然可恢复、可比较、可阻断。

3. Admission 与 Verification 策略

Admission 的目标不是“更多上下文”，而是“只让有资格的上下文进入”。

最低规则建议如下：

1. 无来源不升权
   没有 source + provenance_span 的内容，只能作为草稿假设，不能作为决策依据。

2. 过 TTL 不复用
   超过 valid_until 的 observation 必须重新取样或活体验证。

3. scope 不匹配不引入
   来自另一个 repo 的 skill 可以作为参考，但不应自动成为当前 repo 的高权规范。

4. memory / skill 默认低于 verified tool outputs
   记忆与 skill 是候选材料，不是事实本身。

5. handoff 是 context package，不是事实集合
   必须拆成“已验证事实 / 上游推断 / 决策 / 待补信息”。

Verification 则要求系统明确回答：

我要做的这个动作引用了哪些 claim？这些 claim 分别绑定到哪些证据？证据是否覆盖了动作范围？

建议同时生成 claim table，最小字段包括：

• claim_id
• claim_text
• source_object_ids
• authority
• freshness
• coverage_ref
• used_by_action_id

4. 与完整性绑定的写权限规则

建议把动作至少分成五级。

关键不是分级本身，而是把 allowed_action_level 绑定到上下文对象与证据完整度。

如果当前上下文只支持 L1，就不能因为模型“很自信”而执行 L3；如果只读了文件一部分，就不能获得整文件重写权；如果没有实时观察真实环境，就不能对生产对象做 destructive action。

5. 运行时变量处理

强烈推荐这条规范：

任何“当前态”都不应作为持久事实写入记忆；它应该在动作时刻通过工具解析。

例如：

• runtime.now_iso
• runtime.git_branch
• runtime.k8s_context
• runtime.db_schema_hash
• runtime.feature_flags

这些变量应具备以下属性：

• runtime_bound = true
• ttl = 0 或极短
• 不进入抽象记忆
• 默认不进入 skills
• 在 claim table 中标注 resolved_at

6. 注意力策略治理

建议把通知、告警、cron、health-check、agent 自评、自我改进产物，统一归入四级策略。

这条策略最重要的组织含义是：

Agent 不允许把全体事件统一下调为 silent。

只有 attention policy service 能决定通知等级；执行层最多只能建议重分级，不能直接改人类注意力通道。

7. 记忆整合规则

Consolidation Gate 的最小规则：

1. episodic store 与 abstract store 物理分离
   episodic 是原始证据，不可覆盖；abstract 是派生知识，可版本化，但不能反写 episode。

2. 默认保留原始 episode，默认禁止每轮 consolidate
   这与 Faulty Memory 的结论一致。[2]

3. 只有在模式稳定时才允许生成抽象
   条件包括：同类 episode 足够、近期无冲突、评估显示收益。

4. 抽象更新必须 diffable
   新旧记忆要可比较、可回滚、可标注新增或删除的适用条件。

5. 高风险抽象必须 human-in-loop
   包括任务策略、审批规则、法律、财务、安全相关抽象。

6. 伤害性能的 memory item 应退役，而不是继续压缩。

五、监控、应急与实施路线

1. 监控与可观测性

AI Agent 的 observability 不能只看延迟、tokens、request count。它需要 reasoning-level telemetry，包括：

• reasoning depth
• tool execution graph
• retries
• memory context size
• tokens per successful execution
• planning duration
• skill activation set
• claim table coverage
• write diff size
• rollback time

相关工程文章也指出，传统 observability 很难覆盖 Agent 的规划、记忆检索、工具调用、验证与重试链路。[11] SREGym 也强调 live 环境中，状态会持续变化，信号不完整，并与故障竞争同一时间轴。[3]

对 Context Governance 来说，至少意味着三件事：

1. trace 必须可回放
   不只记录请求和响应，还要记录当时装配了哪些 context objects、触发了哪些 skills、执行前 claim table 长什么样、哪些 gate 放行了。

2. provenance 需要绑定到行动
   一次文件 diff、一次 DB 写入、一次 API 调用都应能反查到引用了哪些 claims。

3. 监控重点要从“系统是否活着”扩展到“推理是否稳定”
   reasoning depth 突增、工具 fanout 激增、同一目标重试超阈值、memory context size 异常膨胀、skill 激活集合异常变化，都应成为治理指标。

2. 事件响应与 playbook

当发现 Context Governance 事故时，推荐六步处理：

1. 冻结自治
   立即停用 L3/L4 写权限。不要先要求模型解释自己，先止血。

2. 保全状态
   保存会话、context objects、skill activation、tool stdout / stderr、checkpoints、外部系统快照。注意：官方 checkpoints 不一定覆盖 bash 或外部写入。[7]

3. 导出 claim table
   定位这次动作基于哪些 claims。

4. 按污染类型归因
   判断是 authority、temporal、completeness、provenance、handoff、skill、attention-policy、evidence misgrounding，还是 consolidation erosion。

5. 修复治理层，而不只是修 prompt
   部分读整写就改 Write Harness；stale runtime fact 就改 runtime binding；skill 滥用就改 registry 与 TTL。

6. 补基准与回归测试
   把事故固化成 admission test、action-gate test、write-harness test 或 memory-gate test。

3. 工程师检查清单

上线前

• 是否为每类上下文对象定义了 source / authority / freshness / scope / ttl？
• 是否存在把 runtime value 当作长期事实写入 memory 或 skills 的路径？
• 任意 L2 以上写入，是否强制经过统一 Write Harness？
• 是否为 DB、Git、外部 API 定义了 L0–L4 动作级别？
• 关键 skill 库是否有版本、TTL、staleness、owner、最近验证时间？
• 长期记忆是否区分 episodic 与 abstract store？
• 是否有针对错误 handoff、stale memory、partial-overwrite 的回归测试？

运行时

• 当前会话激活了哪些 skills？是否有冲突或过期项？
• 高风险动作是否能反查 claim table？
• 当前上下文中是否出现 unknown provenance 或 stale but reused？
• 重试、fanout、reasoning depth 是否超阈值？
• 是否有 P0/P1 事件被误降级到 P2/P3？
• 任意 destructive write 是否有 dry-run、diff、backup、snapshot？

事故后

• 导出完整 trace 与 context object snapshot。
• 标记污染类型与发生阶段。
• 确认 blast radius：代码、数据、通知、记忆、skills、handoff 哪些受影响。
• 从“写权限为何被授予”逆推到“哪个 gate 失效”。
• 将事故加入 benchmark / harness regression。
• 更新风险文档与分级策略。

4. 产品经理检查清单

上线前

• 是否定义了哪些结论可自动执行，哪些只能建议？
• 是否定义了 P0–P3 注意力等级，而不是只有“通知 / 不通知”？
• 是否定义了哪些业务对象必须 human-in-loop？
• 是否把“减少打扰”“自动修复”与“不可错过的提醒”区分开？

运行时

• 用户是否能看见系统基于哪些证据作出建议？
• 用户是否能一键查看 diff、rollback、source trace？
• 用户是否能区分系统观察、系统推断、系统建议、系统已执行动作？
• 对异步和长任务，是否有“静默但可审计”的模式，而非直接 silent？

事故后

• RCA 是否追问“哪个上下文被错误升权”，而不只追问“模型为什么答错”？
• 是否把事故转成新的产品 affordance：审批、diff 预览、恢复、来源显示、skill 版本提示？
• 是否更新了用户心智：哪些功能是“建议器”，哪些是“执行器”？

5. 分阶段路线图

6. 建议跟踪指标

六、开放问题与局限

第一，本报告优先采用论文、官方博客、官方或半官方复盘、第一人称工程文章。其中 arXiv 论文与 Anthropic 官方材料的可信度最高；SaaStr 和个人工程复盘提供了有价值的事故形态；NextFuture 与部分 DEV 文章更适合作为模式信号，而非单独裁决依据。[9][10]

第二，Faulty Memory 论文内部对同一 ARC-AGI 退化实验有不完全一致的表述：摘要写“fails on 54%”，正文附近又出现“降到 54% 正确率”和“fails on 46%”两种说法。这个不一致不影响“consolidation 会造成严重退化”的主结论，但严格引用时应保留不确定性。[2]

第三，本次对话中的“当前时间污染”“partial-read overwrite”“cron silentification”“幻觉化文档引用”是重要私有个案，但不是公开可重复的外部资料。本报告将其作为治理设计的内部证据，而非外部经验事实使用。

第四，本文提出的 Context Compiler、Write Harness、Attention Policy Harness、Consolidation Gate 是治理模式，不是现成商用品。它们的价值在于把近一年的论文与事故经验收束为工程约束；真正落地时，仍需结合现有 agent stack、权限系统、消息系统和运维平台适配。

综合来看，2026 年关于 Agent 的最大进展，不是“模型终于足够会编程”，而是研究与工程实践开始承认：

可靠性首先是上下文治理问题，其次才是生成能力问题。

如果不把 authority、freshness、scope、coverage、provenance、handoff、skills、attention 和 memory 全部纳入治理，Agent 系统只会在更强自治能力的推动下，把原本局部的小错更快、更稳、更难追踪地放大成系统性事故。

参考文献

[1] Strick Sheng, Ziyue Wang, Liyi Zhou. When Agents Overtrust Environmental Evidence: An Extensible Agentic Framework for Benchmarking Evidence-Grounding Defects in LLM Agents. arXiv:2605.08828. https://arxiv.org/pdf/2605.08828

[2] Dylan Zhang, Yanshan Lin, Zhengkun Wu, Yihang Sun, et al. Useful Memories Become Faulty When Continuously Updated by LLMs. arXiv:2605.12978. https://arxiv.org/pdf/2605.12978

[3] Jackson Clark, Yiming Su, et al. SREGym: A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios. arXiv:2605.07161. https://arxiv.org/pdf/2605.07161

[4] Harsh Tatsat, et al. Beyond the Black Box: Interpretability of Agentic AI Tool Use. arXiv:2605.06890. https://arxiv.org/pdf/2605.06890

[5] Anthropic. Claude Code Auto Mode. https://www.anthropic.com/engineering/claude-code-auto-mode

[6] Anthropic. Equipping Agents for the Real World with Agent Skills. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

[7] Anthropic. Enabling Claude Code to Work More Autonomously. https://anthropic.com/news/enabling-claude-code-to-work-more-autonomously

[8] SaaStr. Replit’s New Release Addresses Most of the Challenges We Hit Vibe Coding — But Is Prosumer Vibe Coding Really Ready for Commercial Apps Yet? https://www.saastr.com/replits-new-release-address-most-of-the-challenges-we-hit-vibe-coding-but-is-prosumer-vibe-coding-really-ready-for-commercial-apps-yet/

[9] GoldenWing360. 10 Security Mistakes Claude Code and Copilot Make in Production. DEV Community. https://dev.to/goldenwing360/10-security-mistakes-claude-code-and-copilot-make-in-production-584l

[10] Ryan Patel. 9 Ways AI Coding Agents Break in Production (May 2026). NextFuture. https://nextfuture.io.vn/blog/9-ways-ai-coding-agents-break-in-production-may-2026

[11] AWS Community Builders. Why Traditional Observability Breaks with AI Agents. DEV Community. https://dev.to/aws-builders/why-traditional-observability-breaks-with-ai-agents-3cn0

[12] Vilius Š. Managing 150+ AI Agent Skills at Scale: What Broke, What I Built. DEV Community. https://dev.to/vystartasv/managing-150-ai-agent-skills-at-scale-what-broke-what-i-built-1e73

[13] Vilius Š. My Agent Said It Would Fix the Width. It Rebuilt the Whole Site Instead. DEV Community. https://dev.to/vystartasv/my-agent-said-it-would-fix-the-width-it-rebuilt-the-whole-site-instead-1ch6

[14] Vilius Š. It Still Forgets. DEV Community. https://dev.to/vystartasv/it-still-forgets-3bj8

[15] Vilius Š. My Cron Jobs Failed. I Didn’t Check. DEV Community. https://dev.to/vystartasv/my-cron-jobs-failed-i-didnt-check-lg1

[16] Cat Chen. X post on Claude Code skills and American English. https://x.com/CatChen/status/2055408245724832230

[17] Amjad Masad. X post related to Replit incident. https://x.com/amasad/status/1946986468586721478

[18] Eyal B. Six Claude Code Skills That Close the AI Agent Feedback Loop. DEV Community. https://dev.to/eyalb/six-claude-code-skills-that-close-the-ai-agent-feedback-loop-10bb