3.1 Context 构建管线
3.1.1 System Context 的动态编译
生产级 Agent 的 System Prompt 不应只是仓库中的一个长字符串。模型每轮实际接收到的 System Context，需要根据 Agent 版本、当前任务阶段、用户身份、工作区规则、剩余预算、可用工具和选中的 Skill 动态生成。其角色更接近一次“编译”：多个来源按优先级合并，冲突被处理，超出预算的内容被压缩或移除，最终得到本轮可执行的模型视图。3.1.2 Context Builder 的处理流程
Context Builder 在每次模型调用前执行一条确定性管线： 候选信息至少从 Agent 配置、Task State、Session、Workspace、Memory、Knowledge、Skill Registry 和 Tool Registry 中产生。管线应先做身份和权限过滤，再做相关性排序，不能为了排序方便先把跨租户内容交给检索器或模型。对于外部内容，还要保留来源和信任等级，避免检索到的文档或网页把自身文本伪装成高优先级指令。3.1.3 优先级与 Token 预算
Context 构建不能只按相似度排序。一个实用的优先级函数通常同时考虑：- 约束强度：平台政策和明确业务规则高于经验性建议。
- 任务相关性：是否直接影响当前阶段的判断与行动。
- 时间有效性：当前环境事实高于已经过期的历史结论。
- 来源可信度：权威系统事实高于未经确认的模型摘要。
- 执行依赖：即将调用的工具说明和验收条件应优先保留。
- 信息增量：与已选内容重复的信息应合并或移除。
- Token 成本：同等价值下优先采用更紧凑、可引用的表达。
3.1.4 用 Context Policy 与 Manifest 管理模型输入
每次模型调用都应生成一份 Context Manifest，记录模型究竟看到了什么，而不只是保存最终拼接文本。Manifest 至少包括：
Manifest 为三类工作提供基础：开发时解释模型为什么遗漏某项信息；评估时比较两个 Agent 版本的 Context 差异；安全审计时确认某条敏感内容为什么进入了模型输入。只记录 Prompt 文本无法稳定完成这些任务，因为同一文本片段的来源、权限和版本可能完全不同。
企业应把上下文层级、检索范围、预算分配、压缩阈值、工具披露和敏感内容处理统一定义为 Context Policy，并与可运行的 Agent 版本绑定。模型、Prompt、Skill 或 Knowledge 索引变化后，Context Policy 仍决定它们如何组合。这样才能把“偶然在某次调用中看见了什么”转化为可测试、可回放的工程行为。
在漏洞修复任务的“变更实施”阶段，一份精简的 Manifest 可以是：
3.2 Context 生命周期与压缩
随着任务推进，消息、工具结果和文件内容会持续增长。将完整历史永久放进窗口，会同时带来成本、延迟和注意力退化；简单截断最早内容，又容易丢失初始目标和关键决定。Harness 应把原始历史保存在外部状态中，并根据当前阶段构造一个分层的活动上下文：3.2.1 Commit、Compact、Rebuild 与 Validate
对话压缩不是普通摘要。它要支持下一轮继续执行，因此至少保留：- 原始目标、成功标准和不可变约束；
- 已确认事实及其来源，区分事实、假设和模型建议；
- 已做决定、决定原因和被否决方案；
- 已执行行动、工具结果和副作用；
- 当前 Plan、Todo、阻塞与下一步；
- Artifact、工作区路径和外部对象 ID；
- 用户偏好、审批结果和权限模式；
- 失败尝试及避免重复的原因。
- Commit：将结构化事实提交到 Task State、Workspace 或相应资产库。
- Compact：把可叙述历史转换为摘要，附带来源和覆盖范围。
- Rebuild：用新摘要、当前状态和最近消息重新构造 Context，并检查关键约束是否仍在。
- Validate：对目标、未解决项、权限模式和关键证据做完整性检查，并用续行用例验证行为没有明显漂移。
- 事实保留率：关键事实、约束和决定是否完整保留。
- 继续成功率：压缩或 Reset 后能否在不重复大量探索的情况下继续。
- 矛盾率：摘要是否与工具事实、Task State 或最新指令冲突。
- 引用可用率：外部 Artifact 和分页引用是否仍可访问。
- 成本收益：减少的 Token 与额外压缩调用、读取轮次之间的平衡。
3.2.2 AgentScope：让大结果退出窗口而不退出任务
Framework 路径下，应用团队可以根据场景定义压缩阈值与保留尾部，并把超大工具结果卸载到 Workspace。下面的 AgentScope 配置表示：历史达到 30 条消息时进行压缩，保留最近 10 条；过大的工具结果不继续内嵌，而是写入外部文件并在 Context 中留下引用。3.3 Session、Task State 与 Workspace
3.3.1 区分 Call、Session 与 Task
这三个边界经常被合并为“会话”，但它们解决不同问题：
一个 Session 可以发起多个 Task；一个长 Task 也可以在多个 Session 中被查看、干预和恢复。将 Task ID 绑定为消息线程 ID，会限制后台执行、多人协作和跨渠道续接。Harness 应分别保留两者，并显式记录关联关系。
3.3.2 用状态事实支持恢复
任务状态可以用三种互补表示：- Event Log 记录发生过什么，适合追踪因果、审计和重建。
- Snapshot 记录某一时刻的聚合状态，适合快速读取当前视图。
- Checkpoint 表示可以安全恢复执行的位置，除 Snapshot 外还要包含 Continuation、幂等和环境依赖。
- append_event：追加带版本与因果关系的事件；
- load_task_state / commit_task_patch：读取和提交权威状态；
- save_snapshot / load_snapshot：保存和读取聚合视图；
- put_artifact / get_artifact：存取带元数据的对象；
- create_checkpoint / resume_checkpoint：在安全点保存与恢复；
- search_workspace / read_range：为 Context Builder 提供按需访问。
3.3.3 Workspace 的外部工作记忆模型
Workspace 为 Agent 提供可寻址、可检查、可逐步修改的外部工作空间。它可以是代码目录、文档空间、数据分析目录、远程文件系统或受控对象存储视图。与 Memory 的主要区别是：Workspace 服务当前任务的显式工作过程，内容通常可被用户直接查看和编辑；Memory 则是跨任务选择性保留的经验和事实。3.3.4 文件与 Artifact 的生命周期
Harness 对 Workspace 中的对象至少要记录：稳定 ID、路径或对象引用、内容类型、创建者、来源、版本、权限范围、所属任务、状态、校验摘要和保留期限。 Artifact 可以经历：3.3.5 案例：把任务世界放在模型窗口之外
在 AgentScope 的 Workspace 约定中，指令、长期记忆、知识、Skill、Subagent、Plan 与任务状态可以形成可检查的文件结构。结合本章案例，可以组织为：3.4 Memory 与企业知识
3.4.1 四类 Memory
Memory 不是一个无限增长的历史数据库。它是 Harness 有选择地写入、检索、更新和遗忘的信息，用于改善后续决策。按功能可分为四类：
Working Memory 与第 3.3 节的 Task State 关系最紧密，不一定长期保留。Episodic Memory 要保留当时条件和 Outcome，避免把一次偶然成功当成普遍规律。Semantic Memory 需要来源与更新时间。Procedural Memory 如果已经稳定且可复用，最好升级为受版本治理的 Skill，而不是长期停留在自由文本记忆中。
3.4.2 Memory 的写入与使用
“每次任务结束自动总结并写入 Memory”很容易造成污染。Harness 在写入前应判断：- 这条信息是否会在未来任务中产生可预期价值？
- 它是经过环境验证的事实，还是模型推测或用户临时表达？
- 它应属于哪个用户、项目、租户和保留周期？
- 是否包含敏感、受限或依法不应长期保存的数据？
- 是否已经存在，应该新增、合并、更新还是标记冲突？
- 如果未来错误，谁可以纠正或删除，派生索引如何清理？
3.4.3 让 Knowledge 提供事实、Memory 提供经验
企业 Knowledge 是由组织维护、具有来源和时效的业务事实，例如制度、产品说明、技术文档、数据字典和经营数据；Memory 是 Agent 从任务和用户交互中选择性积累的经验或个体信息。两者都可以通过检索进入 Context，但治理责任不同：
通用知识库的切分、向量化和召回算法不是本章重点。Harness 更关心的是：当前任务是否需要这项事实；调用方是否有权获得；来源是否仍有效；多个来源冲突时如何呈现；答案是否需要引用证据；检索结果是否含有试图改变 Agent 行为的非可信指令。
面向 Harness 的知识接口应返回结构化证据，而不仅是一段拼接文本：
3.4.4 AgentScope：用双层记忆保留经验
一种实用实现是把“原始记忆流水”和“已整理长期记忆”分开。AgentScope 将当日抽取的事实追加到 memory/YYYY-MM-DD.md，再周期性合并、去重到 MEMORY.md；前者保留来源过程，后者在每轮按策略进入 System Context。对话压缩前还可以先 Flush 关键事实，避免摘要把可复用经验一起抹掉。 在漏洞修复任务中，下面的内容适合写入不同位置：
这一区分可以阻止最常见的记忆误用：把一次任务的临时状态当成长期经验，把模型总结当成企业事实，或把尚未验证的方法直接推广到所有项目。
3.5 Skill 与渐进式能力披露
3.5.1 Skill 的能力资产模型
Tool 告诉 Agent “能做什么动作”，Skill 告诉 Agent “在某类任务中如何正确使用若干动作”。一个 Skill 可以由指令、脚本、模板、示例、检查清单和参考资料组成，封装经过验证的任务方法，例如服务故障排查、合同审阅、数据质量分析或发布前检查。 Skill 不等于一段 Prompt，也不等于 Tool 的别名。它通常包含模型需要判断的步骤，也可以调用确定性脚本和工具；它不直接拥有额外权限，只有在当前用户、任务和环境允许时，相关能力才能执行。3.5.2 发现与按需加载
当企业积累数百个 Skill 时，全部注入每轮 Context 会迅速耗尽窗口，也会让模型选择错误能力。渐进式披露可分为三层：- 发现层：模型只看见名称、简短描述、适用条件和主要风险。
- 选择层：Harness 根据任务、权限和环境解析候选 Skill，加载完整 Manifest。
- 执行层：只有真正需要某一步时，才读取详细指令、脚本、模板和参考资源。
3.5.3 案例：把成功修复沉淀为 Skill
一次任务成功，不意味着它已经成为可复用能力。团队应先从 Trace 中提取稳定步骤，移除特定任务 ID、临时路径和一次性判断，为脚本和模板补充测试，再形成 Skill。下面是一份精简的 SKILL.md：3.5.4 将 Skill 纳入发布与回归
企业需要把 Skill 当作软件资产管理。Skill Registry 至少记录所有者、作用域、版本、依赖、权限需求、支持的 Agent / Model、测试结果、发布日期、弃用状态和使用效果。 Skill 的评估不应只看是否被模型选中。还要比较启用前后的任务成功率、步骤数、工具错误、人工修改量、成本和安全事件；对于很少被采用或持续降低效果的 Skill，应调整描述、缩小适用范围或下线。 线上 Trace 必须能够定位到具体 Skill 版本。latest 指针适合开发，不适合不可追溯的生产执行。Agent 版本可以锁定允许的 Skill 集与版本范围；紧急修复通过新 Agent 版本、受控热补丁或明确的策略覆盖生效，并触发相关回归集。HarnessAgent 的 Skill Repository 可以连接项目目录、Git 或企业 Registry，使能力资产按需发现。无论 Repository 位于本地还是共享服务，Skill 的所有权、依赖、权限、评估和版本都应纳入企业统一治理。
3.6 多租户资产治理与反退化
3.6.1 用作用域和元数据建立资产边界
Context、Memory、Knowledge 和 Skill 都可能跨任务复用，但不能默认全局可见。企业应建立一致的作用域模型：
检索和 Context 构建必须先确定调用身份、租户、项目和任务，再查询允许作用域。不要先跨作用域召回再在生成端“提醒模型不要泄漏”，因为内容进入模型输入时，隔离已经失败。
每项资产都应携带最小治理元数据：来源、所有者、作用域、版本、创建与更新时间、权限、敏感级别、保留周期、内容摘要、派生关系和状态。Memory 还需要可信度与适用条件，Knowledge 需要生效时间与权威来源，Skill 需要依赖和评估基线，Context Summary 需要覆盖事件范围。
统一元数据使 Harness 可以用同一套 Policy 决定“能否读取、能否写入、如何引用、何时过期、如何删除”，也使 Agent 版本能准确绑定所依赖的资产版本。
3.6.2 防止污染并支持真正的删除
- 记忆污染：错误推测、失败轨迹或恶意输入被长期写入，并在未来任务中被当作经验。
- 指令污染：外部文档、工具结果或 Memory 中的文字被错误提升为高优先级行为规则。
- 跨租户污染：索引、缓存、摘要、Artifact 或评估数据把一个租户的信息带入另一个租户。
- 禁止新的读取与 Context 注入；
- 删除或隔离原始内容；
- 清理索引、缓存、摘要和其他派生数据；
- 更新引用该资产的 Manifest 与 Skill；
- 保留法律允许且最小化的审计证明；
- 触发受影响 Agent 版本的验证或重新发布。
3.6.3 把资产变更纳入反退化闭环
Context Policy、Memory、Knowledge 和 Skill 的任何更新都可能改变 Agent 行为。企业应把资产变更纳入与代码相同的发布链：3.6.4 三种 HarnessAgent 运行形态如何实现上下文与状态
同一个HarnessAgent 在不同运行形态下使用相同的逻辑对象，但存储与恢复责任不同：
本地形态便于快速验证任务与 Context；嵌入式服务需要补齐身份、Task 和外部 Artifact；分布式 Worker 进一步要求共享状态、执行租约、Sandbox 恢复和资产版本锁定。运行位置发生变化时，不应改变 Context、Session、Workspace、Memory 和 Skill 的语义。