JieGou has evolved.
Since this post was published, JieGou has pivoted from an AI automation platform to an AI-powered operations company delivering managed marketing and operations services. Learn about our managed services →
2026 年 2 月 27 日，OpenAI 和 Amazon 宣布了 Frontier agent 的有状态运行时环境 —— 在 agent 会话的工具调用之间持久保存的文件系统和记忆。这是一项有意义的能力。每次运行之间忘记一切的 agent 从根本上受限。
但持久记忆本身对企业 AI 来说是不够的。问题不在于 agent 是否应该记忆——而在于谁控制它们记什么，谁能看到。
持久 Agent 记忆的承诺与风险
持久记忆使 agent 能力显著提升。一个记得您团队首选沟通语调、审批阈值、客户细分的 agent——每次运行都会变得更好。
风险同样明显。一个拥有不受控持久记忆的 agent 可以：
- 积累过时或不正确的事实，随时间降低输出质量
- 在部门之间泄露信息，当记忆没有范围限定时
- 阻碍合规审计，当没有学到什么、何时学到、从哪里学到的追踪记录时
- 创建隐藏依赖，当下游工作流依赖不透明的 agent 状态时
对于受监管行业——医疗保健、金融服务、政府——不透明的持久记忆不仅是治理缺口。而是交易终止者。
14 项有状态能力中的 13 项：已在 JieGou 中
当我们将 Frontier 的有状态运行时与 JieGou 的现有架构进行评估时，发现 14 项有状态能力中已有 13 项被覆盖：
| 能力 | JieGou 覆盖情况 |
|---|---|
| 结构化输入/输出状态 | 带验证的配方 I/O 模式 |
| 步骤间数据流 | 工作流执行器中的 previousStepOutputs 映射 |
| 基于状态的条件分支 | 带表达式求值的 ConditionStep |
| 循环状态管理 | 带迭代跟踪的 LoopContext |
| 并行执行状态 | 带故障级联的 Promise.allSettled |
| 审批门状态 | 带检查点恢复的 ApprovalPauseError |
| 共享记忆（多 agent） | StepExecutionContext 上的 sharedMemory 映射 |
| 收敛循环状态 | 带评估反馈注入的 ConvergenceLoop |
| 检查点/恢复 | 带按步骤跟踪的 WorkflowCheckpointV2 |
| 知识检索状态 | 带自动上下文解析的 RAG 上下文 |
| 品牌语调状态 | 带部门范围的品牌语调配置 |
| 术语表状态 | 按部门的术语表上下文注入 |
| 少样本学习状态 | 从运行历史中精选的少样本示例 |
唯一的缺口：跨工作流持久 agent 记忆 —— 在不同工作流执行之间持久保存的事实。
第 14 项能力：Agent 工作空间
我们构建了 Agent 工作空间来弥补这个缺口——但有一个关键设计决策：每一条持久状态默认都是受治理的。
Agent 工作空间是一个结构化键值存储，范围限定为账户内的某个 agent。每个条目跟踪：
- Key：描述性标识符（如
preferred_tone、primary_contact、approved_budget） - Value：学到的事实（JSON 可序列化，最大 10 KB）
- Source：条目如何创建——
auto（LLM 提取）、user（手动设置）或step_output（从工作流步骤捕获） - Run ID：哪次工作流运行产生了此条目
- Timestamp：最后更新时间
这些来源元数据是受治理状态与原始持久记忆的区别所在。
工作原理
-
上下文注入：当配方在关联了 Agent 工作空间的工作流中执行时，工作空间条目被格式化为
<agent_workspace>部分并注入到提示上下文中——与术语表、少样本示例和 RAG 文档并列。 -
自动捕获：工作流步骤完成后，可选的捕获步骤使用轻量级 LLM 调用从输出中提取持久事实。只有值得跨未来运行持久保存的事实才会被保存——而非临时细节。
-
手动策展：用户可以通过 API 检查、编辑、添加和删除工作空间条目。这不是一个黑盒——而是一个受治理的数据存储。
设计约束
- 每个工作空间最多 100 个条目 —— 防止无限制的记忆增长
- 每个条目值最大 10 KB —— 保持条目聚焦和可检索
- 约 2,000 令牌预算用于提示注入 —— 工作空间上下文不会挤占实际任务
- 部门范围限定 —— 工作空间继承与 JieGou 其他部分相同的访问控制
为什么受治理的状态 > 原始持久记忆
| 维度 | 受治理状态（JieGou） | 原始持久记忆（Frontier SRE） |
|---|---|---|
| 可见性 | 每个条目都有来源追踪（源、运行 ID、时间戳） | 状态存在于 agent 运行时内部 |
| 可审计性 | 与审计日志集成；合规团队可检查 | 运行时状态未暴露给治理层 |
| 范围限定 | 部门范围限定，RBAC 强制执行 | 会话范围；跨工作流范围不明确 |
| 大小控制 | 硬限制（100 条目，每条 10 KB） | 文件系统持久化——没有固有限制 |
| 过时性 | 时间戳 + 手动策展实现事实卫生 | 没有内置的事实过期机制 |
| 合规性 | API 访问用于自动合规检查 | 需要自定义工具来检查 agent 状态 |
根本区别：Frontier 的有状态运行时使 agent 更强大。JieGou 的受治理状态使 agent 更强大且更可审计。
与 Frontier 有状态运行时的比较
Frontier 的有状态运行时环境是令人印象深刻的工程。持久文件系统、跨工具调用记忆以及与 Amazon 基础设施的集成创造了一个强大的自主 agent 执行环境。
但它是为 agent 能力设计的，而不是企业治理。运行时状态为 agent 使用而优化——而不是为合规团队检查、部门边界执行或审计追踪捕获而优化。
JieGou 从相反方向处理持久状态：治理优先，能力其次。Agent 工作空间不如完整文件系统灵活——这正是要点。约束（结构化条目、硬限制、来源追踪）是功能，而不是限制。
对于构建实验性 AI agent 的团队，Frontier 的方式很有吸引力。对于在受监管环境中部署 AI、每一条 agent 状态都必须可解释和可审计的团队，受治理状态是唯一可行的路径。
开始使用 Agent 工作空间
Agent 工作空间现已通过 JieGou API 提供：
- 为账户中的任何 agent 创建工作空间
- 将其与工作流关联 —— 执行期间自动注入工作空间上下文
- 启用自动捕获 —— 让系统从步骤输出中提取持久事实
- 审查和策展 —— 检查条目、编辑值、移除过时事实
工作空间与 JieGou 现有治理体系集成：审计日志、RBAC、部门范围限定和合规导出都适用于工作空间操作。
结论：治理就是差异化因素
持久记忆是强大 AI agent 的基本要求。每个平台都将很快拥有它。
差异化因素不在于 agent 是否能记忆——而在于您是否能看到、控制和审计它们记的东西。对于企业 AI，受治理状态不是锦上添花。它是区分生产部署与科学实验的要求。
JieGou 的受治理状态架构覆盖 14/14 项有状态能力——每个状态变更都可见、可审计、有范围。这就是企业 AI 所需的基础。
了解更多关于 JieGou 的治理架构或与 OpenAI Frontier 的比较。