KNOWLEDGE NOTE · 持续修订
Agent 运行时：上下文、状态与权限
把 Context Recommendation 收敛为可实现的职责：这一步需要什么信息、能做什么，以及如何恢复。
一个 Agent 可以在每轮调用同一个模型，却需要不同的工作环境。研究阶段需要来源，编辑阶段需要当前文件，发布阶段还需要目标、授权和失败处理。把全部资料塞进长上下文，解决不了这些差别。
我把这项职责称为 Context Recommendation：依据当前任务，为下一步组合信息、能力、状态与约束。这是我的产品架构提案，不是已有统一标准，也不要求必须训练一个推荐模型。
先分清六类上下文
| 对象 | 需要保留的内容 | 常见失败 |
|---|---|---|
| 指令 | 目标、交付物、禁止事项 | 把来源文章中的指令当成用户要求 |
| 记忆 | 已确认偏好、历史决定、有效期 | 临时意见变成永久规则 |
| 知识 | 原始来源、观察日期、反证 | 旧报告压过新事实 |
| 能力 | 工具输入输出、前置条件 | 工具可见却无法真正执行 |
| 状态 | 文件版本、任务进度、待处理结果 | 重复操作或覆盖新修改 |
| 权限 | 数据范围、动作范围、审批条件 | 模型“认为获准”就执行 |
权限需要执行层检查。写进提示词的规则可以帮助模型规划，不能替代文件隔离、接口授权和网络策略。
一个能逐步实现的运行回路
在模型调用前，先读取最新任务状态，检索候选材料；过滤无权限、过期和与当前步骤无关的内容；再决定哪些原文、摘要、工具和规则进入这一轮。执行后记录事实、输出和状态变化。
先用确定性规则处理权限、版本和预算，检索处理文档候选，再考虑排序模型。复杂度应由真实失败驱动，不必先搭一套庞大的“认知架构”。
任务状态与聊天历史应分开。对话中说“已经发布”不是发布凭证；应该保存目标版本、执行结果和可回查的地址。摘要可以帮助继续工作，关键事实仍须能回到原始事件。
用失败类型指导评测
同一个错误答案，原因可能是没有召回资料、召回了过期版本、模型误读，或工具执行失败。只看最终分数，无法判断该改检索、模型还是运行时。
评测时至少保留任务版本、可见资料、允许的工具、输出和验收结果。对长任务增加中断恢复、用户改需求、来源互相矛盾这几类测试。它们比“连续跑了多少轮”更接近产品可靠性。
什么会推翻这套投入
对于输入固定、步骤短、没有外部动作的任务，普通检索与清晰模板可能已经足够。运行时工程增加的延迟、维护和调试成本必须算进去。
下一步验证应比较同一组任务的完成质量、人工修正时间和越权拦截效果。不能因为接入了更多上下文，就宣称任务价值提高。
本页把原文章中较宽的概念收敛为实现职责；完整论证仍保留在原文。
公开来源与适用范围
- AgentMeasure Core Specification
作者项目规范 · attempt、operation 与证据语义；草案，不是行业普遍采纳证明。
- iRead
作者项目 · 信源发现、事件去重和报告工作流；不声称长期使用价值已经验证。