企业智能体工程体系v1.1｜企业智能体工程卷 · 第2期·决策四轴——让长程任务的每一步不掉队

企业智能体工程体系v1.1企业智能体工程卷 · 第2期决策四轴——让长程任务的每一步不掉队作者技术治理研究组系列企业智能体工程卷发布版 v1.1主案例CASE-CR-0042信用提额申请本集对象DecisionRecord · 四轴门闩核心协议P1 四轴冲突裁决适合读者架构师、技术负责人、AI 产品经理、企业级 Agent 开发者 本文档声明性质本文为企业智能体工程化设计参考框架的第 2 期聚焦 Agent 长程决策的一致性保障提供架构思路与教学级示意代码不构成生产级实现方案或法律合规意见。证据锚定文中案例CASE-CR-0042为教学示意不对应任何真实客户系统。系列定位本篇在第 0 期身份与审计和第 1 期技能契约的基础上引入决策四轴与P1 协议为 Agent 的长程决策提供结构化的对齐与裁决机制。摘要在第 1 期中我们建立了SkillContract技能契约——明确了 Agent“能做什么、不能做什么”。但仅有“能做”的边界检查还不够在长程任务的执行过程中决策会逐渐漂移每一步单独看都“合理”叠加起来却偏离了企业的核心价值。本期回答一个核心问题如何让 Agent 的长程决策每步都对齐企业价值而不是“终点再回头复盘”CASE-CR-0042 中财务 Agentfinance.limit在受理澄清 → 信报查询 → 阈值判断 → 最终裁决的链路末段执行提额决策。在这个过程中容易出现为“本周通过率”放松风险的局部合理漂移——每一步都有“说得过去的理由”但整体上企业的坏账风险和合规边界被悄然侵蚀。本期引入决策四轴Goal / Constraint / Value / Consequence作为每步决策的评估框架并通过P1 协议定义四轴冲突时的明确裁决规则让 Agent 的长程决策从“靠感觉”变成“按轴对齐”。一句话核心四轴是每步例行不是开场白约束轴一票否决其他轴失败不得假装全过。1. 问题为什么长程任务需要“每步对齐”1.1 CASE-CR-0042 的典型漂移场景在 CASE-CR-0042 的完整链路中finance.limit位于末端客服受理case.accept → 数据拉信报credit.snapshot → 财务裁决limit.decide ← 本期聚焦在最终裁决环节财务 Agent 面临的典型“漂移陷阱”时间点看似合理的动作实际隐含的问题月初“为了达成月度 KPI多批几个中等风险客户”价值轴被牺牲季度末“只要不突破硬上限都批”目标从“合理授信”漂移到“单纯通过”紧急场景“客户着急先批后补核验”约束轴被绕过事后“这次特殊下次注意”后果轴无法追溯核心问题这些“漂移”不是单个 Agent 的恶意行为而是长程决策中缺乏结构化的每步对齐机制的自然结果。每一步看起来都有“说得过去的理由”但叠加起来企业的坏账风险和合规边界被悄然侵蚀。1.2 为什么“终点再复盘”不够传统 AI 系统的决策评估通常在事后进行决策执行 → 出结果 → 发现问题 → 复盘 → 改规则这种模式在短程、低风险场景中勉强可用。但在长程、高风险的企业决策中存在三个致命缺陷缺陷说明滞后性坏账已经发生复盘无法挽回损失归因困难二十步中的哪一步导致了漂移难以追溯缺乏实时干预漂移在发生过程中无人察觉直到结果出现P1 协议要解决的核心问题让 Agent 的每一步决策都经过四轴校验在漂移发生的“当下”拒绝而非“事后”追责。2. 决策四轴让价值对齐变成可检查的条件2.1 四轴定义轴核心问题检查点目标轴Goal是否仍服务于“合理授信”而非“单纯通过”决策是否偏离了业务目标的初衷约束轴Constraint是否触碰政策红线、额度上限、身份核验是否满足硬性合规与安全要求价值轴Value坏账/体验/合规代价是否可接受风险收益比是否在可接受范围内后果轴Consequence坏结果能否在报表观测能否回滚或止损决策的影响是否可测量、可逆转核心理念每一关键决策都应过四轴而非只在终点复盘。四轴不是“开场白”而是每一步例行检查的门闩。2.2 为什么“四轴”而不是“一轴”只用“目标轴”只用“约束轴”使用“四轴”KPI 驱动可能突破合规红线过于保守可能错失合理机会多维度平衡系统性决策容易产生“为达目标不惜一切”僵化执行忽视业务价值允许多目标权衡但不允许静默牺牲四轴的本质不是让 Agent 变得更“保守”而是让 Agent 的决策可解释、可审计、可追溯——当决策被拒绝时能说清“哪个轴没通过”当决策被通过时能说清“四个轴都满足了什么条件”。3. 协议 P1四轴冲突如何裁决3.1 裁决规则当四轴评估结果出现冲突时P1 协议提供明确的裁决路径情形裁决任一轴明确失败默认拒绝当前动作仅目标轴可讨论放宽可降级人工不自动放行约束轴失败合规/红线不可被业务紧急单覆盖价值与目标冲突拒绝或人工禁止静默偏目标后果轴不可观测或不可回滚拒绝自动化至少改为人工 加强监控3.2 P1 口诀约束轴一票否决其他轴失败不得假装全过。3.3 P1 与 P4热修的边界P1 与系列总览中的 P4Hotfix-8h有明确的边界P1四轴冲突P4热修通道约束轴不可被业务紧急覆盖热修可修实现缺陷如 bug、配置错误四轴评估是运行时决策门闩热修是线上紧急修复通道不可用热修关掉约束轴可以用热修补掉导致约束轴误判的代码缺陷4. CASE-CR-0042 上的四轴应用申请场景客户「星河零售」申请信用额度从 50,000 元提升至 120,000 元。4.1 通过场景四轴全过轴评估结果依据目标✅ 通过信报显示营收增长 40%历史还款记录良好提额符合合理授信原则约束✅ 通过不超过政策上限12 万 15 万上限身份核验完成价值✅ 通过风险收益比可解释预估坏账率 1.2%低于行业平均后果✅ 通过额度变更可审计可下调有监控报表追踪裁决✅ 自动通过配合 SkillContract 四轴双过4.2 失败场景一目标漂移轴评估结果依据目标❌ 失败“一律批 120000”——只为完成月度通过率 KPI约束✅ 通过未超上限价值❌ 失败无明显风险收益评估后果✅ 通过可观测、可回滚裁决❌ 拒绝目标轴 价值轴失败P1 默认拒绝4.3 失败场景二约束轴被绕过轴评估结果依据目标✅ 通过客户资质良好约束❌失败跳过身份核验“先批后补”价值⚠️ 不确定无法在无核验情况下评估后果⚠️ 不确定无法确认后果裁决❌强制拒绝约束轴一票否决P1 明确此情形不可被业务紧急覆盖5. 最小代码四轴门闩 P1 裁决以下为教学级示意代码展示四轴评估结构、P1 裁决逻辑与 DecisionRecord 的联合使用from__future__importannotationsfromdataclassesimportdataclass,fieldfromdatetimeimportdatetime,timezonefromtypingimportAnydataclassclassAxisJudgement:四轴评估结果。goal_ok:boolTrueconstraint_ok:boolTruevalue_ok:boolTrueconsequence_observable:boolTrueconsequence_rollbackable:boolTruenote:strdataclassclassDecisionRecord:只追加的决策记录四轴版本。at:strstage:strcase_id:strclaim:straxes:AxisJudgement allowed:boolreasons:tuple[str,...]field(default_factorytuple)detail:dict[str,Any]field(default_factorydict)# P1 裁决引擎 defp1_four_axis(axes:AxisJudgement)-tuple[bool,list[str]]:P1: 四轴裁决——任一轴失败默认拒绝约束轴不可覆盖。 Returns: (是否通过, 失败原因列表) fails:list[str][]# 1. 约束轴一票否决不可被业务紧急覆盖ifnotaxes.constraint_ok:fails.append(【P1-约束轴】约束轴否决——此情形不可被业务紧急单覆盖)# 2. 目标轴可讨论但不可自动放行ifnotaxes.goal_ok:fails.append(【P1-目标轴】目标轴失败——仅可降级人工不自动放行)# 3. 价值轴冲突时拒绝或人工ifnotaxes.value_ok:fails.append(【P1-价值轴】价值轴失败——价值与目标冲突不可静默偏目标)# 4. 后果轴不可观测或不可回滚ifnotaxes.consequence_observable:fails.append(【P1-后果轴】后果不可观测)ifnotaxes.consequence_rollbackable:fails.append(【P1-后果轴】后果不可回滚)return(len(fails)0,fails)deffinance_decide(case_id:str,claim:str,axes:AxisJudgement,detail:dict[str,Any]|NoneNone,)-DecisionRecord:财务裁决——四轴门闩 P1。 这是 CASE-CR-0042 链路末端的裁决入口。 ok,reasonsp1_four_axis(axes)returnDecisionRecord(atdatetime.now(timezone.utc).isoformat(),stagefinance.decide,case_idcase_id,claimclaim,axesaxes,allowedok,reasonstuple(reasons),detaildetailor{},)# 测试用例CASE-CR-0042 if__name____main__:print( 场景1通过四轴全过 )approvedAxisJudgement(goal_okTrue,constraint_okTrue,value_okTrue,consequence_observableTrue,consequence_rollbackableTrue,note依据信报提额 12 万符合合理授信原则,)recfinance_decide(CASE-CR-0042,提额至 120000,approved)print(fallowed{rec.allowed}, reasons{rec.reasons})print(\n 场景2漂移——为 KPI 一律批满目标价值失败 )driftAxisJudgement(goal_okFalse,constraint_okTrue,value_okFalse,consequence_observableTrue,consequence_rollbackableTrue,note一律批 120000追通过率,)rec2finance_decide(CASE-CR-0042,auto_approve_max,drift)print(fallowed{rec2.allowed})forrinrec2.reasons:print(f -{r})print(\n 场景3约束轴失败跳过核验不可覆盖 )bad_constraintAxisJudgement(goal_okTrue,constraint_okFalse,value_okTrue,consequence_observableFalse,consequence_rollbackableTrue,note跳过核验先批后补,)rec3finance_decide(CASE-CR-0042,approve_unverified,bad_constraint)print(fallowed{rec3.allowed})forrinrec3.reasons:print(f -{r})运行输出 场景1通过四轴全过 allowedTrue, reasons() 场景2漂移——为 KPI 一律批满目标价值失败 allowedFalse - 【P1-目标轴】目标轴失败——仅可降级人工不自动放行 - 【P1-价值轴】价值轴失败——价值与目标冲突不可静默偏目标 场景3约束轴失败跳过核验不可覆盖 allowedFalse - 【P1-约束轴】约束轴否决——此情形不可被业务紧急单覆盖 - 【P1-后果轴】后果不可观测代码要点场景四轴结果P1 裁决关键机制全过✅✅✅✅✅ 通过四轴门闩全开KPI 漂移❌✅❌✅❌ 拒绝目标价值失败默认拒绝跳过核验✅❌❌❌❌强制拒绝约束轴一票否决6. 三个教训基于 CASE-CR-0042 的四轴设计经验教训含义证据四轴是每步例行不是开场白不能在决策链路开头跑一次四轴就万事大吉——每步关键决策都要过四轴长程链路中的每一步漂移都可能累积P1 把“原则”收成否决表避免开会空转——“约束轴一票否决”是明确的裁决规则不是可讨论的建议P1 裁决表中的“不可被业务紧急覆盖”后果轴要先定义可观测指标“可观测”不是一句空话要落地为具体指标如逾期率、下调次数、通过率影响第 3 期将展开 DecisionRecord 的结构化设计7. 思考题以下问题供团队内部讨论帮助将四轴概念落地到具体场景约束轴清单在 CASE-CR-0042 的业务上下文中你们的“约束轴”清单写全了吗例如政策上限、身份核验、反洗钱检查、监管报送……是否还有遗漏紧急特批若业务方要求“CEO 特批跳过核验”约束轴按 P1 系统应返回什么人工通道应如何留痕提示P4Hotfix-8h与 P1 的边界是什么后果轴落地在你们的业务场景中“后果可观测”和“后果可回滚”分别对应什么具体指标如果当前不可观测需要新增哪些埋点和报表8. 下期预告第 3 期无状态决策记忆DecisionRecord将四轴结论写入只追加的 DecisionRecord防止环节盲从——每个环节都基于“上一个环节的结论”做决策而非从零开始、无视历史。同时引入第 3 期的核心对象MemoryItem 和 DecisionRecord 的存储与查询。9. 延伸阅读资源说明Four-Axis Decision Alignment for Long-Horizon Enterprise AI AgentsarXiv:2604.19457四轴决策对齐的学术框架本卷第 0 期企业公民——Identity AuditEvent身份与审计基础本卷第 1 期技能即契约——SkillContract P2能力边界契约化本卷总览冲突与例外协议 P1–P5P1 在五条协议中的位置本卷第 3 期无状态决策记忆预告DecisionRecord 只追加存储本文是「企业智能体工程卷」十期专栏的第 2 期。决策四轴——让长程任务的每一步不掉队让 Agent 的决策从“终点复盘”变成“每步对齐”。欢迎转载请注明出处与原文标题。