企业的Agent工程:从Codex源码到合规前置

AI时代，谁掌握工作流入口，谁就掌握了竞争主动权——当Claude Code、Codex、Cursor的底层能力趋同，真正的壁垒不再是“模型更强”，而是“能否把Agent合规地嵌入业务”。与此同时，AI安全的主战场已经从“模型说错话”迁移到“智能体做错事”：一个能自主调用工具、访问网络的Agent一旦失控，破坏面远超一次错误回答。

这意味着，对企业而言，合规从来不是Agent上线后再补的一道审批，而是必须写进架构第一行代码的原生要求——身份可追溯、权限可收紧、行为可回滚，这些监管要求恰好就是生产级Agent架构里本来就该有的东西。本文围绕一个具体问题展开：Agent框架或自研Harness如何做到合规前置，从而降低后续的整改、审计、返工成本。全文分四部分：企业使用Agent的趋势、Codex与Pi-Agent源码里现有的合规设计满足了什么又缺了什么、企业自研或采购Agent时的技术解法、以及结论与启示。

01

目前企业使用Agent的趋势

1.1 Agent正在成为工作流的新入口

过去十几年，企业信息化完成的是“数据线上化”；今天，企业面临的是“谁掌握工作流入口”的竞争。正如演语科技陈冕所言：“AI时代的赢家，是那些掌握工作流入口的平台或个人。”当Claude Code、Codex、Cursor的底层能力趋同——文件系统、Shell、Git、搜索、通信这几大工具集已基本收敛到同一套——真正的壁垒不再是谁的模型更强，而是谁能把Agent合规地嵌入现有业务工作流。

Indie Fox（@indie_maker_fox）的判断更直接：“定制化Agent开发已经是企业内的核心业务，Agent内部原理可以说是未来程序员的编程基础了。”这意味着理解Agent的两层循环、工具执行链路、上下文管理、多Agent协作，不再是底层框架团队的专属知识，而是每一个要把Agent嵌入业务的工程团队都要具备的基本功。

1.2 主战场的迁移：从“模型说错话”到“智能体做错事”

2026年AI安全产业研究报告给出了一个关键判断：AI安全的主战场已经从LLM Safety（模型说错话）迁移到Agentic Security（智能体做错事）。OpenClaw事件——72小时6万星标、4个月冲到34.6万星标——在短短几个月内完成了对产业界、消费市场和监管者的“三重教育”：一个能自主执行操作、调用工具、访问网络的Agent，一旦失控，破坏面远超一次错误回答。

这个迁移直接决定了企业做Agent工程时不能只优化“回答质量”，而必须同时把工具调用、身份归属、权限边界、行为留痕当作架构的一等公民。

1.3 企业采纳节奏：从试点工具到核心业务系统

Agent在企业里的落地路径正在发生变化：一年前，Agent多以“个人生产力工具”的形态出现（写代码、查资料、做摘要）；今天，越来越多企业把Agent接入客服、风控、运营等核心业务流程，让它具备真正的执行权限——能改数据、能调外部系统、能代表企业对外发起请求。执行权限的扩大，直接放大了失控的代价。

这也是为什么“合规前置”从可选项变成了必答题：当Agent只是辅助工具时，出了问题人工兜底就够；当Agent成为业务系统的一部分，它的每一次决策都需要和传统业务系统一样接受审计、留痕、可回滚的约束。传统认知里，“做Agent”和“过合规”是两条并行的工作线：先把功能做出来，再找合规团队补一道审批、加一层日志。这在Agent时代已经行不通——原因很简单：Agent的自主执行能力本身就是风险的来源，而不是风险之外的东西。一个Agent能干什么、怎么被拦截、谁能追溯到它做了什么，这些问题的答案不是写在合规文档里，而是刻在Task Owner Loop、工具注册表、审批链这些代码结构里的。

这正是行业里安全左移（Shift-Left）乃至智能左移（Shift-Smart）的核心逻辑：安全检查前置到设计阶段（威胁建模）、数据与训练阶段（投毒防护）、CI/CD阶段（持续红队）、部署阶段（实时护栏）四个环节，而不是等上线后靠“补丁”救火。中国企业同时面临密评、等保、数据安全法等刚性约束，这些约束恰好和“安全左移”的技术趋势重合——监管要求的可追溯、可控制、可撤销，与生产级Agent架构里的身份JWT、三层拦截、rollout日志，本来就是同一件事的两种表述。

下文从两份深度源码分析——Codex（echovic《拆开Codex》）与Pi-Agent（dgzhuya《三层架构》）——出发，回答一个更具体的问题：这些目前最主流的生产级Agent架构，到底有没有把合规做进代码结构里？哪些机制现成可用，哪些是空白？

02

Codex与Pi-Agent源码分析：现有Agent是否具备合规设计

生产级Agent架构总览

2.1 已满足：六项内建于代码结构的合规机制

两层循环——合规追溯的时间轴基础。用户按下一次回车，启动的不是一次模型调用，而是两层嵌套循环：

• 外层Task Owner Loop管理任务生命周期（Submission→Active Turn→Pending Queue→Cancellation）

• 内层Sampling/Action Loop负责与模型的多轮交互（发送请求→流式响应→解析输出→工具执行→继续采样或结束）

这两层循环天然给出了一条可审计的时间轴：一次业务操作对应哪个Turn、一个Turn里发生了几次工具调用、每次调用的起止时间，都能沿着状态机精确回放。没有这层分离，“这次事故是哪一步做的”这类审计问题根本无法回答。

工具两张表——最小权限原则的架构落地。Codex的工具系统有一个核心设计：模型可见的工具规格（PlannedTools）与本地执行注册表（ToolRegistry）同源构建，但故意不相等。模型看到“我可以调用shell”，但真正执行时，ToolRegistry会先经过权限、沙箱、审批策略的检查。call_id把模型的调用请求和本地的执行结果闭环绑定，确保结果不会被错误关联到其他调用。这个设计的合规意义在于：“模型认为自己能做什么”和“系统实际允许它做什么”必须是两个可以独立收紧的控制面。企业接入Agent时，业务侧只需要控制PlannedTools的可见范围，安全侧独立收紧ToolRegistry的执行策略，两者互不干扰。

三层独立拦截——纵深防御。生产级Agent的安全治理是三层互不依赖的拦截：审批（AskForApproval）让模型执行操作前先问用户，ReviewDecision记录批准/拒绝；Permission Profile定义不同操作的权限级别，审批通过不代表可以任意执行；平台沙箱提供操作系统级隔离，即使前两层都通过，进程仍在沙箱边界内运行。网络访问额外有一条独立决策链，防止Agent被诱导访问内网敏感资源。三层拦截“各自独立”这一点很关键：单层失效不会导致安全事故，这正是纵深防御在工程上的准确定义。

身份可追溯——Agent Identity不等于登录身份。Codex区分Access Token（用户登录凭证）与Agent Identity JWT（每个任务签发的独立身份）。每次工具调用、每次网络请求都携带Agent Identity，使审计可以精确追溯到“哪次任务的哪一步”，而不是笼统的“某个用户”。这与“智能体是第三类身份”这一判断完全一致——人类身份、服务账号身份之外，Agent需要独立的身份治理体系。

三种状态存储——审计留痕与工作集分离。同一段Agent会话同时存在于三个地方：ContextManager（实时工作集）、rollout JSONL（完整对话日志，追加写）、SQLite ThreadStore（持久化索引）。上下文压缩时，被压缩的只是模型的工作集，不是审计所需的完整历史——被丢弃的内容仍可从rollout日志重建。这直接对应合规要求里“系统可以为了性能优化上下文，但不能丢失可追溯性”的诉求。Memory系统进一步与对话历史分离：History记录“发生了什么”，Memory记录“学到了什么”，这种分离让企业可以对Memory单独设置留存策略、脱敏规则，而不必牵动完整的审计日志。

Pi-Agent单向依赖分层——架构解耦即可定责。dgzhuya拆解的Pi-Agent开源框架展示了另一个维度——用严格分层让职责边界本身变得可审计。核心规则是依赖方向必须单向向上：底层永远不知道上层的存在，删除上层依赖后，下层仍可独立编译和运行。当模型适配层、循环引擎、业务逻辑严格分层，出问题时定位责任边界的成本会大幅下降——三层架构给出的是三个可以独立审计的责任面，而不是一坨互相纠缠、谁都说不清的代码。

2.2 不满足：五处现有架构没有覆盖的合规空白

把这六项机制列出来容易让人觉得“合规已经做得很好了”，但对照真实的企业合规要求逐条核对，会发现现成的开源Agent架构里还有明显的空白，这些恰恰是自研或选型时最容易被忽视、事后返工成本最高的部分。

空白一：拦截依据是静态规则，不是动态风险评估。三层拦截（审批/Permission Profile/沙箱）的判断逻辑都是预定义的静态规则——“这个命令要不要审批”是配置写死的，不会根据当前任务上下文、Agent近期行为模式、环境异常程度动态调整。一个被诱导的Agent只要单次操作没有触发静态规则，就能顺利通过三层拦截，静态规则防不住这种“合规地作恶”。

空白二：Harness自改进没有内建的强制回滚门禁。Codex、Pi-Agent目前都不具备让Agent修改自身Harness代码的能力，这本身谈不上违规，但行业趋势已经指向Harness自改进（RHI、Darwin Gödel Machine等），而“每次改动配一个可推翻的预测”这类可回滚原则，目前只是方法论层面的建议，没有一款主流框架把它做成代码里的强制门禁——谁先做，谁就能在这条能力线上线时天然合规，而不是等风险发生后再补救。

空白三：默认走国际算法栈，不满足国密合规要求。Codex、Pi-Agent的身份签发、传输加密默认使用JWT/TLS这类国际算法体系，没有原生支持SM2/SM3/SM4、TLCP等国密算法。中国企业如果要满足密评、等保等要求，这是一个必须在应用层做适配、而不能指望上游框架解决的空白。

空白四：Memory/RAG数据没有数据主体权利响应机制。现有Memory系统的设计目标是效率和上下文管理，不是隐私法规遵从——没有内建“某个用户要求删除/更正自己数据”这类请求的响应接口。当 Agent 的长期记忆里混入了用户的个人信息，企业目前只能靠应用层自己实现数据主体权利响应，框架本身不提供这层能力。

空白五：供应链完整性靠生态惯例，不是强制密码学校验。依赖库、模型权重的来源验证目前主要靠npm/cargo/pip这类包管理生态的惯例（版本锁定、签名可选），不是强制的完整性校验机制。这和生成式AI密码应用类合规指引里要求的“来源真实性验证”之间存在明显差距——供应链投毒风险不是靠信任生态就能解决的。

这不是在说Codex、Pi-Agent设计得不好——恰恰相反，六项已满足的机制说明合规原生的架构是可行的，只是目前的实现深度还停留在“通用信息安全”层面，没有覆盖中国企业特有的合规要求和Agent特有的新风险。这正是第三部分要解决的问题。

03

企业自研或采购Agent，如何实现合规前置？我们的解决方案

面对第二部分指出的五处空白，企业无论是自研Agent框架还是采购现成方案，都需要针对性地补齐。以下按问题逐条给出技术思路。

3.1 问题一：静态规则拦截不够→引入动态风险评估引擎

技术思路：在三层拦截之外增加一层风险评分——基于当前任务的上下文、Agent近期的行为模式、访问的资源敏感度，实时计算一个风险分数，分数超过阈值触发额外的人工审批或降级执行。这不是要替换静态规则，而是在静态规则之上叠加一层动态判断，弥补“单次操作合规、但行为模式异常”这类场景的盲区。可以从最简单的行为基线建模开始——记录Agent正常操作的频率、时段、资源访问范围，偏离基线就触发告警，逐步迭代到更复杂的风险评分模型。

3.2 问题二：Harness自改进缺乏强制回滚→把“可回滚”做成架构门禁

技术思路：任何允许Agent修改自身配置、工作流、甚至代码的能力上线前，先把“变更前快照+一键回滚”做成硬性前置条件，而不是事后补救的应急预案。具体做法是给Harness的每一次自我修改都生成一个可验证的“变更提案”，包含修改前状态、修改依据、预期效果，人工或自动化门禁在提案通过后才允许生效，且随时可以回滚到修改前状态。这一条的成本很低，但很少有团队在设计初期就把它当作强制项，往往是出了事故之后才补上——这正是“前置vs后置”两种路径成本差异最大的地方。

3.3 问题三：国密合规空白→建适配层，不等上游框架

技术思路：在应用层加一层密码适配层，把Agent身份签发、传输加密的默认实现替换为SM2数字证书、TLCP安全传输协议，而不是寄希望于上游开源框架原生支持。国内已经有相关指引给出了具体的技术清单（例如：《生成式人工智能系统密码应用指引》）可以直接参照，比如为每个Agent签发唯一SM2数字证书、用TLCP建立安全传输通道。这一层适配工作量不小，但只需要做一次，之后可以复用到所有基于同一底层框架构建的Agent应用上。

3.4 问题四：Memory隐私合规空白→给记忆系统加数据主体权利接口

技术思路：Memory系统的存储层增加一个索引维度——记录每条记忆关联的数据主体（哪个用户、哪次交互），并提供标准化的查询、更正、删除接口。当收到数据主体权利请求时，能精确定位并处理相关记忆条目，而不需要在整个Memory库里人工排查。这个能力最好在设计Memory系统的存储schema时就规划进去，事后补是几乎要重构存储层的大动作。

3.5 问题五：供应链完整性不足→强制依赖签名校验+SBOM

技术思路：对训练框架、依赖库、模型权重文件建立强制的完整性校验机制——用消息鉴别码或数字签名验证来源真实性，并维护一份软件物料清单（SBOM），记录每个组件的来源、版本、校验值。企业可以从最关键的组件（模型权重文件、核心运行框架）开始强制校验，逐步扩展覆盖范围，而不必一开始就要求全量覆盖。

3.6 采购vs自研：合规能力验收清单

3.7 组织配套：技术方案不能单独生效

无论技术方案多完善，都需要组织流程跟上——三层独立拦截、身份治理、审计日志这些机制再完善，如果没有人定期审查审批策略、复盘沙箱逃逸的红队报告、维护Agent权限的最小化，架构本身也会随业务扩张而“合规腐化”。架构是地基，组织流程是让地基持续生效的维护机制，两者缺一不可。建议设立跨部门的AI合规治理机制（技术、法务、业务线共同参与），定期复盘审批策略和红队结果。

04

结论和启示

结论一：合规原生的Agent架构是可行的，现成的开源实现已经证明了这一点。两层循环、工具两张表、三层拦截、身份可追溯、三种状态存储、单向依赖分层——这六项机制不是为了合规而设计，但恰好构成了合规所需要的技术基础。企业不需要从零发明这套架构，直接复用这些成熟模式就能拿到大部分分数。

结论二：现成方案覆盖的是通用信息安全，中国企业特有的合规要求需要自己补。国密算法适配、数据主体权利响应、动态风险评估、Harness自改进的强制回滚——这几项是目前主流开源Agent框架没有覆盖、也不太可能由境外开源社区主动补齐的部分，企业必须自己规划技术投入。

结论三：合规前置和合规后补的成本差距，会随Agent自主性的提升而持续扩大。当Agent只是辅助工具，出问题人工兜底成本可控；当Agent深度嵌入核心业务、甚至开始参与修改自己的Harness，事后补合规意味着要在一个已经运行的复杂系统上做外科手术式的重构，风险和成本都远高于在架构设计阶段就把这些要求写进去。

对企业来说，真正的启示不是“要不要用Agent”，而是能不能在拥抱Agent带来的效率红利的同时，把合规前置为架构的第一性原则，而不是上线后的补丁。第二部分的六项已满足机制加五处空白，本质上就是一份可以直接拿去对照打分的评估清单；第三部分的技术思路，就是把清单上的空白逐条填平的具体路径。越早填，后续的整改、审计、返工成本越低——这正是“合规前置”这四个字的全部含义。