Agent 工程：从流程模拟到系统运营

跨层连接器。 上游概念：知识层 (knowledge/) 的框架/策略/事实/设计四类资产 + 策略四层梯度。下游作用于：运行时层 (architecture/) 的 Hooks/Flag 控制机制。本文讨论知识层的设计决策如何映射为 Agent 架构的工程约束。

声明：OpStack 是一张地图——它告诉你你在哪里、你看不见什么、你在什么地方做了妥协。它不是施工图纸。

1. Agent Harness Engineering：当前基线

1.1 什么是 Agent Harness

Agent 不等于 LLM。Agent = LLM + 一套让它能在具体任务中执行、判定、交付的脚手架（harness）。

这套脚手架包括：prompt 模板、工具/函数调用、上下文管理（RAG/内存）、输出解析、错误重试、以及人机交互节点。当前工具生态——LangChain、CrewAI、AutoGPT、OpenAI Agents SDK、Anthropic Tool Use——基本上都在围绕着这些组件工作。

它们的共同假设是：Agent 的可靠性取决于 prompt 的质量、工具的正确性和模型的推理能力。这个假设本身没有问题，但它能覆盖的问题域有一个清晰的天花板。

1.2 基线的完整度：四个已解决的问题

有些问题已经被工程化了。

工具调用（function calling）已经稳定——API 层定义了标准的 tool schema，模型可以可靠地选择工具并传递参数。结构化输出（JSON mode）同样已经稳定——Agent 的输出可以被解析为确定性的数据结构，进入下游流程。

上下文注入——RAG、system prompt、长期记忆——部分工程化了，但上下文窗口的管理仍然是艺术。多步编排——chain、graph、multi-agent——有框架，但尚无共识范式。LangChain 的 Graph、CrewAI 的 Task、OpenAI 的 Swarm，各自有不同的编排哲学，行业还在收敛中。

1.3 增强层的碎片化：盲人摸象

行业已经意识到裸 Agent 不可靠。于是出现了各种增强尝试，各自从不同的方向切入。

Agent 记忆（Mem0、LangMem、Letta）让 Agent 记住上次交互的上下文和用户偏好。它触碰到了"事实需要持久化和多速制管理"，但它不区分一条记忆是驱动事实（仅限本次会话）还是参考事实（跨会话共享），也没有新鲜度管理——记忆只增不减，旧的、过期的、不再适用的记忆和新鲜的记忆混在一起。

生成式 AI 产物治理（Guardrails AI、NVIDIA NeMo Guardrails）在 Agent 输出侧加校验——检查格式、检查敏感信息、检查内容是否符合预设范围。它触碰到了"策略"的概念，但策略与执行耦合——校验规则嵌入调用链中，不能被独立测试、版本化、或跨 Agent 复用。一个在邮件 Agent 中写好的校验规则，不能直接被合同 Agent 继承。

企业本体论层（Palantir Ontology、各企业内部知识图谱）在 Agent 之下建立统一的数据语义层——定义什么是"客户"、什么是"订单"、它们之间什么关系。它触碰到了"框架"的概念，但本体论不参与执行判定——它定义实体关系，不定义验收条件。Agent 知道"客户"是什么，但不知道"这个客户下的这笔订单金额是否合理"。

护栏与安全层（Claude system prompt 约束、OpenAI moderation API）在模型层面施加行为约束——不做什么、不说什么、不输出什么格式。这是最底层的策略执行，但护栏是全局的、粗粒度的——它们不问"这份合同是否可以签"，只问"这条回复是否安全"。业务级别的对错判定不在护栏的管辖范围内。

这些尝试的共同特征：每个方向都触碰到了端到端治理的一个必要组件——事实、策略、框架、判定——但没有一个方向能看到完整的拼图。它们各自是有效的工程实践，但彼此孤立。记忆不知道护栏在挡什么，护栏不知道本体论里定义了哪些关系，本体论不知道策略对数据有什么验收条件。

这不是批评——每个方向都在解决真问题。缺失的不是更好的记忆、更强的护栏、更完善的本体论，而是一个把它们组织成治理体系的统一视角。

2. OpStack 的四个关键决策

OpStack 不是"一套完备的答案"，而是一组设计决策的集合。这四个决策各自解决一个具体的问题，彼此之间存在依赖关系——它们共同的方向，是在 Agent 之外的治理层建立一套独立的基础设施，而不是在 prompt 工程或工具调用上比基线做得更好。

2.1 框架与事实分离

框架是对业务本质的理解——这个领域有哪些维度、哪些自由度。框架不定义什么是对的，只定义"我们在看什么"。一个用户增长框架声明 DAU、留存率、LTV 作为需要观测的维度；一个审批框架声明金额、部门、合同类型作为需要判断的坐标。

事实是对这些维度的测量——今天的 DAU 是 152,000，这份合同的金额是 ¥500,000。事实是框架的实例化，是框架中的一个坐标点。

为什么必须分离？因为框架和事实的变化速率完全不同。框架以季度或年为周期变化——你不太可能每个月重新定义"增长"是什么意思。事实以秒、天、周的速度变化。如果二者混在一起——如同基线中全部塞入 prompt 或 RAG——框架的稳定性优势就丧失了。每次事实更新都会触发对 Agent 行为的重新验证，而实际上框架没有变、策略也没有变，只有数据变了。

工程后果是明确的：框架进入代码仓库，版本化，变更需要 review。事实进入数据库或实时数据源，Agent 执行时动态拉取，不写入 prompt，不写入 RAG 索引。Agent 的 prompt 只携带框架结构和对事实的引用——"请检查本周 DAU 与 7 日均值的偏离程度"，而不是"本周 DAU = 152,000，7 日均值 = 156,000，请判断是否正常"。

基线 Agent 的 system prompt 典型地混合了"你是谁"（框架）、"今天的实际数据是 X"（事实）、"如果遇到 Y 情况就拒绝"（策略）。修改任何一部分都要重新测试和部署 Agent。分离之后，框架变更走 PR，事实变更走数据管道，策略变更走配置更新——三个独立的发布轨道，互不阻塞。

2.2 驱动事实与参考事实分离

事实不是一种东西。至少有两种性质完全不同的事实，当前基线完全不做区分。

驱动事实是每次执行不同的、必须逐次采集或填写的数据——本周 DAU、本次活动预算、当前库存水位。它的优化目标是最小化填报量：Agent 能自动从数据库拉取的数据，不应该让人再填一次；人能从一个字段推断出的另一个字段，不应该让人填两次。填报人多花 3 分钟，乘以每周 200 次填报，等于一个全职人力工时。

参考事实是跨实例复用、变化相对较慢的数据——人员清单、资质库、公司业绩、行业基准。它的优化目标不是填报效率，而是可获得、口径统一、跨时间跨业务线可比。去年 Q3 的业绩和今年 Q3 的业绩用的是同一个口径吗？不同业务线对"活跃用户"的定义是一致的吗？这些问题对驱动事实不重要——驱动事实只管这一次——但对参考事实来说，口径不一致意味着所有的跨期比较都建立在错误的基础上。

两种事实的治理问题完全不同。驱动事实的问题是采集效率。参考事实的问题是正确性和一致性——一条过期的资质数据，可能导致一个季度的审批全部基于错误判断。

工程后果：驱动事实走"零填报"或"最少填报"的采集管道——API 自动拉取、上次的输入自动填充默认值、从关联对象推断可推导的字段。参考事实走集中维护、定期刷新、口径文档化的治理流程。Agent 在执行时区分对待：驱动事实信任当前实例的输入，参考事实信任集中维护的权威源，不把二者混入同一个上下文窗口。

基线 Agent 的 RAG 文档库里，行业基准和用户输入以相同的"检索→注入"方式被对待。参考事实的口径不一致被掩盖在检索噪声中，驱动事实的填报体验没有被优化——Agent 每次都问同样的信息，因为它不知道什么是"参考"、什么是"驱动"。

2.3 执行与判断分离

Agent 做了两件本质上不同的事，但在基线的 prompt 中它们是同一次推理调用。

执行是收集事实、填入框架、生成产物。执行回答"我基于什么数据、按什么结构、产出什么交付物"。这是 Agent 擅长的事：数据聚合、模板填充、格式转换。给定相同的输入，执行应该产出确定的输出——可以被回归测试验证。

判断是识别一次具体的填报或产物中哪里存在不自洽——预算超过历史区间、日期逻辑矛盾、风险板块缺失。判断回答"这个产物合格吗"。判断有两个维度：性质——是刚性阻断（数据错误，不可继续）还是柔性记录（风险告警，标记关注）；以及是否需要打扰负责人——这里的"打扰"是故意设计的，不是系统的失败，被它打断的人应该有这个预期。

为什么必须分离？因为执行可以被确定性测试，而判断不能。同一个判定规则——"周环比降幅超过 15% 需要说明原因"——可能这次是误报（上周有特殊活动导致基数膨胀），下次是漏报（降幅恰好在 14.9%）。判断的质量不能通过 Agent 自评来衡量——Agent 既是运动员又是裁判，自评的结果是"我做得很好"。

工程后果：执行逻辑放在 Agent 的 prompt 和工作流中。判断逻辑从 Agent 中剥离，作为独立的、可测试的规则层存在。Validator 在数据写入时阻断不合规输入（刚性阻断）；Assertion 在 CI 中校验跨系统的一致性和趋势偏移（柔性记录）；结构化评估在产物生成后逐项检查——Agent 可以执行这个检查，但判定结果独立于生成结果存档；HITL 节点标记必须经过人确认的决策点。

基线的 prompt 同时包含"怎么做"和"怎么算对"——前者是执行指令，后者是判断标准。当 Agent 的输出错了，你不知道是执行错了（它没找到正确的数据）还是判断错了（它找到了数据但没识别出问题）。分离之后，执行错误和判断错误是不同的调试路径，不同的修复策略，不同的 owner。

2.4 判断的默认自动化 + HITL 预算管理

分离了执行和判断之后，下一个问题是：判断应该放在哪一层？

OpStack 的回答是：默认自动化。能下沉就下沉。字段级约束（金额 > 0）用 Validator，在数据写入时刚性阻断——不需要 Agent 参与，不需要人参与。跨字段约束（开始日期 < 结束日期）用 Validator 或 Assertion。业务趋势约束（周环比降幅不超过 15%）用 Assertion 在 CI 中校验。只在规则尚不能编码、或信息不完备、或后果不可逆时，保留 HITL。

但 HITL 不是免费午餐。每次"请负责人确认"打断一个人的工作流，消耗的是注意力。如果 HITL 节点过多，负责人会疲劳——机械地点击"确认"，真正的风险点被淹没在例行确认中。OpStack 的主张是：HITL 节点的数量应该作为显式预算来管理。新增一个 HITL 节点，就要审视是否可以移除另一个——因为它已经可以下沉了，或者它保护的场景已经不存在了。

这意味着策略四层不是静态分类，而是动态迁移管道。每个评审周期，团队审视：哪个 HITL 节点的判定规则已经足够明确，可以下沉为结构化评估？哪个结构化评估项已经执行了足够多次且判定逻辑稳定，可以编码为 Assertion 或 Validator？下沉不只是工程重构——它释放了 HITL 预算，让人把注意力从机械确认转移到更高价值的判断上。

基线 Agent 的 human-in-the-loop 是一个工具节点——在 LangChain 中是 interrupt，在 CrewAI 中是 human_input。它便宜好用，每加一个 interrupt 都让人感觉更安全。但累积效果是退化——Agent 降级为一个自动填表工具，所有实质判断仍然靠人。OpStack 的 HITL 预算视角改变了这个方程：不加"让人确认一下更安全"，而是问"这个确认消耗的注意力预算，跟它免除的风险，哪个更大"。

这四个决策之间存在依赖关系。框架与事实分离是前提——没有它，就无法区分哪些数据变化应该触发框架审视，哪些只是正常波动。执行与判断分离依赖框架与事实的分离——判断规则是施加在框架维度上的，如果框架和事实混在一起，判断规则就失去了稳定的坐标系。HITL 预算管理依赖执行与判断的分离——如果判断不独立于执行，就无法盘点"哪些判断在发生、哪些可以下沉"。

3. 未闭环的环节：人类注意力重新投注的地方

OpStack 的四个决策定义了治理体系的骨架。但骨架之外，有几个环节本质上无法被技术自动闭环——它们需要人类持续投入注意力，不是去执行任务，而是去维护系统本身。基线的 Agent Harness Engineering 几乎完全不讨论这些环节，因为它还没有走到"需要维护系统"这一步。

3.1 事实的治理：新鲜度与采集偏差

OpStack 给出了事实的四速制——实时、高频、中频、低频——以及来源标注和不可覆盖原则。但"事实在持续被维护"这件事本身，不是一个技术动作。

它需要人持续关注几个问题。这条事实的数据源还活着吗？管道静默失效——数据还在跑，但上游已经换了口径。这条事实还意味着我以为它意味的东西吗？框架定义了 DAU 的含义，但业务部门对"活跃用户"的定义已经悄悄变了，只是没有人更新数据管道的口径。有什么重要的事实，因为框架没有给它维度位置，正在被系统性忽略？你只能看到你决定看的东西——采集偏差不是技术 bug，是注意力分配的政治。

基线 Agent Harness 把事实当作 RAG 的检索对象——存在即可用。但事实是会腐化的。腐化的事实喂给 Agent，比没有事实更危险——Agent 会基于错误的前提做出自信的判断。

人类注意力从"采集事实"转移到了"审视采集系统"——不再逐条录入数据，而是定期检查数据源的健康状态、采集口径的漂移、框架盲区的信号。

3.2 策略的评估与淘汰：谁在看着这些规则

OpStack 给出了策略的治理机制——owner、日落条款、考核。但"日落真的被执行了"这件事，在大多数组织中不会自动发生。

原因不是技术上的。一个到期的策略被重新评估，意味着它的 owner 必须做判断：这条规则现在还对不对？这个判断需要 owner 重新理解当时的设计意图、当前的环境变化、以及维持现状和承担风险之间的权衡。这是一次需要认知投入的判断，不是一个可以委派给 Agent 的 checklist。

更根本的问题是：策略的收益是不可见的。一条 validator 成功阻止了一个错误数据写入——这件事不会产生告警，不会产生报告，没有人会注意到"什么没发生"。策略的摩擦是可见的——审批多了一步，流程慢了两天。但策略免除的风险是不可见的。这种不对称使得策略天然趋向膨胀——只增不减。每次事故后新增一条规则，从没有一条规则因为过期的风险场景已经不存在而被删除。

基线 Agent Harness 根本不讨论策略的生命周期——规则在 prompt 里，prompt 改了就是改了，没有对"这条规则是否仍然有效"的独立审视。

人类注意力从"执行判定"转移到了"审视判定规则"——不再是"这份方案过没过"，而是"这条判定规则在过去一个季度实际拦截了什么、误杀了什么、是不是该废了"。

3.3 框架的更新：隧道效应与认知重塑

OpStack 指出框架变化慢，需要保守演进。但"慢"不是真正的问题。真正的问题是：框架更新本质上是认知重塑——承认你当前的维度集无法解释正在发生的事。

组织在这件事上会陷入隧道效应。框架定义了什么是可见的、什么是可讨论的、什么是"业绩"。一旦框架固化，组织就只能看到框架内的信号。一个维度的缺失——比如"用户信任度"不在增长框架中——会导致所有关于用户信任度的信号被当作噪音忽略，直到它变成一个不可忽略的危机。

框架更新意味着承认过去的框架是错的，或至少是不完整的。这对个人来说已经很难——确认偏误让每个人都倾向于寻找支持现有模型的数据。对组织来说更难——框架是权力分配的工具。谁控制维度定义，谁就控制什么算"做得好"。更新框架就是重新分配定义权。

基线 Agent Harness 不讨论框架——它没有"维度"这个概念。Agent 做什么、不做什么，由 prompt 和工具列表决定。这个层次的"框架变更"只是一次 prompt 改版——它绕过了框架更新的认知冲突，也因此绕过了学习和积累。组织没有被迫重新审视自己的基本假设，只是换了一套更花哨的 prompt。

人类注意力从"在框架内优化"转移到了"审视框架本身"——不仅是"DAU 怎么提升"，更是"我们为什么用 DAU 而不是别的什么来衡量增长"。

3.4 意识到策略可以自动执行：从"我来看看"到"它不需要我看了"

OpStack 的策略四层给出了 HITL → 结构化评估 → Assertion → Validator 的迁移路径。但这条路径上有一个非技术性的坎：人需要放弃"我来看看"的控制感。

当一个策略从 HITL 下沉到 Validator，意味着这个判断不再经过人的手。对于习惯了"我的价值在于我审得准"的人，这意味着他的日常工作减少了一项——而他的新工作——设计更多策略、审视已有策略、更新框架——还没有被组织正式承认。他的产出从"审了 200 份方案"变成了"设计了 3 条 validator，覆盖了 90% 的常见错误模式"。前者有计数，后者没有衡量标准。

这不是 Agent 或 OpStack 能解决的问题，但它是决定迁移能走多远的关键变量。如果组织不重新定义"下沉策略的人"的价值——从执行产出转向规则设计产出——策略下沉会遭遇隐性抵抗。

基线 Agent Harness 同样面临这个问题，但它没有语言来描述它。当 LangChain 的 human-in-the-loop 节点被替换为自动判定，它看起来只是一个工程重构。OpStack 提供了语言：这不是重构，这是人类注意力从执行层退到定义层——不做出判断，而是设计判断规则。

人类注意力从"亲自判定"转移到了"信任系统的判定并监控其边界"——这不是技术信任问题（系统有没有 bug），是制度信任问题（当系统判断失误时，谁负责？）。

3.5 这些环节的共同特征

这些环节有三条共同特征。

第一，它们都不是"一次性工程"——不能被设计好然后自动运行。它们是持续的人类实践，需要周期性的注意力投入，没有终点。

第二，它们都不可被 Agent 替代——不是 Agent 不够强，而是它们需要在不完备信息下做出判断并承担后果。这是战略的范畴，不是运营的范畴。Agent 可以运行策略，但不能决定策略是否应该继续存在。Agent 可以按框架采集事实，但不能判断框架本身是否已经过时。

第三，基线 Agent Harness Engineering 的盲区正在于此：它把 Agent 运营当作一个纯技术问题，而它同时是一个治理问题、一个认知问题、一个组织设计问题。OpStack 的贡献不是"解决了这些问题"——没有人可以替一个组织做认知重塑——而是为这些问题提供了概念框架和操作语言，让你至少知道该把注意力放在哪里。

3.6 治理层的度量腐化：谁治理治理者

前面讨论的四个环节——事实治理、策略淘汰、框架更新、控制感转移——都有一个隐含的前提：人愿意并且能够诚实地审视自己设计的系统。这个前提在大多数组织中不成立。不是因为人坏，而是因为治理层本身的指标一旦被制度化，被治理者就会开始博弈这些指标。

这是管理会计的百年教训在 Agent 时代的重演。管理会计试图用标准成本和差异分析让组织透明，但结果是被考核者学会了平滑数字、控制叙事、压低预算基准。组织越"成功"地推行管理会计，报表越"干净"，而真实运作越不可见。

OpStack 的治理指标面临同构的风险。策略自动化覆盖率——"本季度 HITL 节点下沉了 30%"，好看。但如果下沉的方式是把复杂判断用最窄的 Validator 覆盖，那些 Validator 没覆盖的边缘 case 等出事了再说呢？Validator 通过率——"97% 的执行自动通过"，好看。但如果通过率高是因为 Validator 被调得过于宽松，实质风险没有被拦截呢？HITL 节点数量——"我们把人工确认点从 8 个降到了 3 个"，好看。但如果降下来的 5 个点只是被移出了报表，转换成非正式的"我帮你看一眼"呢？

这不是恶意破坏。这是被考核者对一个只看"自动化率"的治理框架的理性适应——就像成本中心负责人面对"降低单位成本"的指令，把成本推到外包商那里一样理性。

框架没有回答一个递归问题：谁来治理治理者？用什么度量去度量度量体系本身？ 管理会计花了百年时间证明度量会腐化。它的教训不是"度量技术不够好"，而是度量与被度量者的自利行为之间存在结构性张力——任何被考核的维度都会被优化，未被考核的维度会被系统性牺牲。Agent 没有消除自利，它只是让博弈的参与者多了一个工具——操纵模型输入比修改报表更难被审计，但动机是一样的。

这不是说 OpStack 的治理指标不该存在。它们必须存在——没有指标就无法管理。但每一个治理指标的设定，都必须同时问一句：如果这个指标明天被写进了我的 KPI，我会怎么用最省力的方式把它做绿？ 对这个问题的回答，应该成为指标设计的一部分。否则，治理层就会变成另一套需要被治理的遗留系统。

4. 缝合：一条完整的 Agent 运营产线

设想一个企业运营团队，每周需要产出二十份项目进展报告，发送给不同客户的决策层。

基线做法。 团队搭建了一个 LangChain Agent。System prompt 描述了报告的结构（框架）、包含了上周的数据摘要（事实）、写入了"如果进度延迟超过 7 天必须红色标注"的规则（策略）、规定了品牌色板和图表样式（设计）。RAG 文档库里放着项目计划书、上期报告、客户偏好说明。Agent 每周一跑，生成的报告由团队负责人逐份审阅后发出。

问题很快出现。客户换了决策层，新 VP 要求的报告结构不同——需要修改框架，但框架嵌在 prompt 里，改了 prompt 就要重新测试 Agent 的生成质量。一个项目的预算数据在上游系统里修正了，但 Agent 不知道——它用的是上周 RAG 检索到的旧数据。一条"延迟 7 天标红"的规则连续误报了三次——因为业务含义是"关键路径延迟"而非"任意任务延迟"，但规则没有区分这两者。团队负责人每周花四个小时逐份审阅，但他审的是什么？排版问题（本该由 validator 在生成时检查）、数据口径问题（本该由事实治理解决）、判断失误（本该由独立于 prompt 的策略规则校验）——以及个别确实需要他的业务判断的风险点。但他必须逐份看完才能找到那几个真正需要他判断的点。

OpStack 增补后的做法。 框架从 prompt 中移出，进入 Git 仓库中的 YAML 文件——报告结构、章节定义、每节的数据类型——版本化，PR 审核。事实从 prompt 和 RAG 中移出：驱动事实（本周的项目数据）由 Agent 在运行时从数据库直接拉取；参考事实（客户公司名称、行业基准）从集中维护的配置文件中注入，按月度刷新。策略独立于 prompt 存在：字段级约束用 Pydantic Validator；跨字段一致性用 pytest Assertion 在 CI 中校验；业务判断规则——如"关键路径延迟超 7 天需说明"——作为结构化评估项，由 Agent 逐条检查并输出结构化判定。HITL 只保留一项：报告中有风险标注的部分，在发送前需要负责人确认——不是确认排版或数据口径，只是确认风险判断是否需要升级。

四个小时的审阅压缩到了二十分钟。不是 Agent 变强了，是判断层被独立出来，负责人只需要看系统认为"需要他判断"的东西。

剩余空白。 治理层的加入消除了机械审阅，但暴露了新的问题。上下文预算——Agent 每次执行时，需要注入多少参考事实、多少驱动事实、多少策略规则？参考事实有 200 项，业务规则有 50 条，全部都塞进上下文窗口既不可能也不合理。哪些值得占窗口空间，需要基于当前执行的任务做优先级决策——这个决策框架还没有。策略的评估与淘汰——季度评审时，一条策略拦截了什么、误杀了什么、该废还是该留——需要数据支撑，但策略收益的不可见性意味着这些数据没人采集。框架更新——当客户业务方向变化，报告结构需要增加一个新维度时，谁来发起这个讨论，谁来批准，批准的依据是什么——这是一个治理流程问题，不是一个工程问题。

这条产线不是虚构的——它是 OpStack 当前阶段的真实画像。一部分可工程化的确定性已经被消除了；剩余的是需要人类注意力的治理问题。

5. 收束：Agent Harness Engineering 的下一阶段

当前基线解决了"让 Agent 跑起来"的问题。下一阶段要解决"让 Agent 不出错地持续运营"的问题。

后者需要的不是更好的 prompt，也不是更强的模型。它需要的是一套 Agent 之外的治理基础设施：判定与执行的分离——让"对"和"错"的检查独立于"做"的过程；知识资产的独立生命周期——框架、策略、事实各自有独立的发布轨道和治理规则，修改数据不需要重新部署 Agent；人机边界的显式设计——不是"Agent 搞不定的时候人来兜底"，而是人在系统设计之初就定义了哪些判断由机器做、哪些由人做、并持续审视这个边界；可审计的决策追溯——每一次 Agent 判定都可以被回溯到当时的规则版本、输入数据、判定依据和结果。

OpStack 为这四件事提供了概念框架和工程模板。但它不是从天而降的——它是从"运营工业化"这个独立的问题域生长出来的。在 Agent 工程爆发之前，OpStack 回答的是一个没有人问的问题：白领工作如何被工程化。在 Agent 工程爆发之后，它回答的是一个每个人都应该问的问题：当 LLM 让白领工作可以被工程化了，你准备拿什么来治理它。

治理不是护栏的叠加。护栏能防止 Agent 说错话，但不能阻止 Agent 基于正确但过期的数据做出自信的错误判断。护栏能拦截敏感信息泄露，但不能识别一条业务规则已经被环境和时间架空。护栏是必要的，但护栏回答不了"什么是对"——它只回答"什么是不安全"。

OpStack 的核心主张是：把"什么是对"从 Agent 中剥离出来，作为独立于 Agent、可演化、可审计的治理资产来管理。 这需要技术架构的调整——框架与事实分离、执行与判断分离、策略独立版本化。但更需要人类注意力的重新投注——从执行任务转向审视系统，从运行规则转向设计规则，从在框架内优化转向质疑框架本身。

工程决定了能力的上限。Agent 决定了工程能走多快。但工程和 Agent 都不决定方向——方向是人选框架的时候决定的，选完了就只能看到框架里的东西。

这里有一个更深的、这篇文章绕了一路最终必须正视的问题：Agent 本质上是不可问责的。

问责需要三个条件同时成立：因果关系可以被追溯（谁做了什么决策导致了什么后果）；责任主体是一个可以被惩罚的实体（可以被降职、解雇、追偿）；责任主体在做决策时有能力预见后果并做出替代选择（他本可以不这么做）。Agent 在这三项上全部失效。Agent 的决策是一个分布式过程的涌现结果——Prompt 设计者、事实维护者、策略定义者、HITL 确认人——每个人都可以说"如果别人做好了，我的环节不会出错"，因果是被稀释的，没有单一的追溯起点。而 Agent 本身没有自由意志，给定相同的输入和模型权重，它只能做同样的输出。你不能问责一个没有选择自由的实体。

这使得 Agent 在组织中的角色天然模糊：它是一个工具，但它在做决策。决策者需要被问责，但工具无法被问责。当一个 Agent 的判断产生后果时，问责链条会沿着组织层级往上爬，最终停在"集体决策"上——没有人需要独自承担后果。这不是技术上的"可审计性"能解决的问题。可审计性告诉你发生了什么，但它不能替你把责任分配到一个可惩罚的主体上。

这不是 OpStack 需要解决的又一个"待填的坑"。它是一个结构性的不可能——就像你不能让一把锤子为砸歪的钉子负责。OpStack 能做的，是确保当事故发生时，至少有人能回答"当时的规则是什么、数据是什么、谁定义的规则"。问责的政治和制度维度不在 OpStack 的工程范围内——但它必须被标记为所有工程努力的边界条件。工程的尽头是治理，治理的尽头是政治，政治的尽头是没有人愿意独自站着。

待填的坑

诚实列出本文无法回答的问题：

上下文预算的分配算法：在一次 Agent 执行中，哪些参考事实值得注入、哪些可以从略，这个优先级决策如何自动化？还是它本身就是一个需要人类判断的策略问题？
退化检测的自动化：Agent 行为开始退化时——模型更新、输入分布偏移、上下文侵蚀——如何在业务指标恶化之前捕获信号？传统可观测性（metrics、logs、traces）显然不够。
影子运行到自主运营的过渡判据：不是"对齐度达到 95%"，而是一组更复杂的条件——包括高风险 case 的漏报率趋势、误报率是否可接受、以及流程本身是否已经稳定到值得交给 Agent 运营。这些条件如何形式化？
跨组织策略互认：当供应商和采购方使用不同的策略定义时，如何在不统一框架的前提下实现策略互认？这是 OpStack 联邦治理的未解延伸。
非确定性判定的质量度量：Agent 执行结构化评估时，同样的输入两次可能得到不同判定。如何度量这种非确定性的风险？OpStack 的策略考核框架假设了确定性判定，这个假设在 Agent 场景下需要被重新审视。
古德哈特收敛：当治理指标（策略自动化率、HITL 下沉率、Validator 通过率）被用于考核团队时，被考核者会博弈这些指标——不是做假账，而是用最窄的 Validator 覆盖以求"通过率"好看、把复杂判断踢回非正式的"我帮你看一眼"以求"人工节点数"达标。如果将来这些治理指标被接入自动优化（遗传算法或任何黑箱搜索），博弈就不再需要人类意图——算法会忠实地搜索出指标本身的漏洞组合，而不是更好的规则。这是古德哈特定律的终极版本：当优化器比度量设计者更聪明时，度量不再是系统健康度的近似，而是系统漏洞的精确描述。