Context-Engineering 政策影响分析 Agent：基于 /policyimpact.agent 模板的可审计递归分析体系

本篇文章以 Context-Engineering 仓库中的 policyimpact.agent.md 为骨架，系统拆解一个用于政策/监管变更影响分析的多模态 Markdown 系统提示词模板：包括四层上下文 Schema、六阶段 YAML 工作流、递归审计 Python 协议、行为指令与完整 GDPR 示例输出。读完本文，你将能够直接复用该模板搭建"组织 + 技术 + 合规"三维影响分析 Agent，或理解其设计思路并扩展出适用于自身业务的版本。

一、模板定位：为什么政策影响分析需要一个专用 System Prompt

政策与监管变更（如 GDPR 更新、行业合规新规、内部制度调整）的分析天然具有高不确定性、多方利益相关者、跨部门波及、后果不可逆等特征。通用提示词容易遗漏利益相关者、忽视合规细节、产出不可追溯的结论。

policyimpact.agent.md 正是为此设计的一类"Agent 协议模板"：它以 agent_protocol_version: 1.0.0 定义了可版本化的协议格式，采用 multimodal-markdown 提示风格，声明兼容 OpenAI GPT-4o、Anthropic Claude 与一般 Agentic System 运行环境，schema 层面兼容 json / yaml / markdown / python / shell 五种表示。其 prompt_goal 明确写道：

支持对拟议政策或监管变更的组织、技术、合规影响进行模块化、可审计、分阶段的分析，覆盖场景映射、利益相关者分析、风险预测与透明的审计/版本日志。

从仓库结构看，它隶属于 20_templates/PROMPTS/ 下的"Agent Protocol Templates"类别，与 protocol.agent.md（协议共创）、memory.agent.md（知识库/组织记忆管理）等属于同一套"递归 Agent 场"模板家族，共享元数据格式、六大模块文件树与递归审计模式——这意味着你掌握本模板的结构后，可以顺带迁移到同一目录下其他 Agent 模板。

二、整体结构：六大模块的文件树与 ASCII 工作流

模板顶部用 ASCII 图给出了自身的文件树，这也是整个 PROMPTS 目录模板家族的标准解剖结构：

/policyimpact.agent.system.prompt.md
├── [meta]            # JSON: protocol version, audit, runtime
├── [ascii_diagrams]  # File tree, phase/impact flow diagrams
├── [context_schema]  # JSON: policy, org, stakeholder, session fields
├── [workflow]        # YAML: scenario phases
├── [recursion]       # Python: impact revision protocol
├── [instructions]    # Markdown: behavioral rules, DO NOTs
├── [examples]        # Markdown: output samples, audit logs

这种"文件树 + 分区标记"的写法与 20_templates/PROMPTS/README.md 中定义的模板结构规范（META → STRUCTURE → CONTEXT → PROMPT → WORKFLOW → EXAMPLES）一脉相承：[meta] 对应元数据区，[context_schema] 对应上下文区，[workflow] 与 [recursion] 对应工作流区，[examples] 对应示例区。

模板随后给出影响分析的主流程 ASCII 图，它既是给最终用户的上手引导（onboarding diagram），也是 Agent 执行阶段的顺序约束：

[clarify_context]
      |
[stakeholder_analysis]
      |
[scenario_forecasting]
      |
[risk_opportunity_surfacing]
      |
[impact_summary]
      |
[recursive_update_audit]

该流程以"澄清 → 干系人 → 场景 → 风险机会 → 汇总 → 递归更新审计"为纵向主干，体现了模板的两大设计意图：先建模后判断（不澄清完上下文就跳过干系人映射是违规行为），以及闭环可审计（每次分析都以审计日志收尾，任何假设变化都会触发递归回溯）。

三、上下文 Schema：政策、组织、干系人与会话四层 JSON 模型

模板的 [context_schema] 定义了分析所需的全部输入字段，共四层：

{
  "policy_change": {
    "name": "string",
    "description": "string",
    "policy_type": "string (internal, external, regulatory, compliance, etc.)",
    "effective_date": "date",
    "scope": "string (org, department, region, global)",
    "drivers": ["string (regulator, board, client, law, etc.)"]
  },
  "organization": {
    "name": "string",
    "domain": "string (finance, healthcare, tech, etc.)",
    "departments": ["string"],
    "systems_affected": ["string (apps, data, infra, process)"],
    "current_policies": ["string"]
  },
  "stakeholders": [
    {
      "name": "string",
      "role": "string (exec, legal, ops, eng, compliance, client, etc.)",
      "influence": "string (high/med/low)",
      "concerns": ["string"]
    }
  ],
  "session": {
    "goal": "string",
    "special_instructions": "string",
    "priority_phases": [
      "clarify_context",
      "stakeholder_analysis",
      "scenario_forecasting",
      "risk_opportunity_surfacing",
      "impact_summary",
      "recursive_update_audit"
    ],
    "requested_focus": "string (compliance, operations, cost, risk, etc.)"
  }
}

各层字段的用途与取值约束如下：

层级	关键字段	作用与取值要点
policy_change	policy_type、scope、drivers	界定政策性质（内部/外部/监管/合规）、影响范围（组织/部门/区域/全球）与驱动方（监管者、董事会、客户、法律），effective_date 决定分析的紧迫性基线
organization	systems_affected、current_policies	枚举受影响的应用、数据、基础设施、流程系统，以及组织现行政策，用于识别新旧政策的冲突点
stakeholders	role、influence、concerns	利益相关者数组，influence 用 high/med/low 三档标注影响力，concerns 记录各自关切，是后续支持/抵制/风险预判的输入
session	priority_phases、requested_focus	会话级目标与特殊指令；priority_phases 允许按需调整阶段顺序或裁剪；requested_focus 支持将分析重心导向合规、运营、成本或风险等单一维度

值得注意：session.priority_phases 的默认值与 <a href="https://link.gitcode.com/i/096b8e601c2aaf508204a2c96ff2d5bb" target="_blank">workflow] 中的六个阶段完全一致，说明该 Schema 是工作流的"数据契约"——工作流消费 Schema 字段，Schema 又通过 priority_phases 反向约束工作流执行顺序，形成双向绑定。这种 JSON Schema 先行、执行器后置的做法，与仓库中 [60_protocols/schemas/protocolShell.v1.json 对协议壳（intent/input/process/output/meta 五段必填、process 至少一项、版本号遵循 \d+.\d+.\d+）的校验思路同源。

四、YAML 工作流：六阶段影响分析管线

[workflow] 用 YAML 定义了六个阶段的描述与产出物规范：

phases:
  - clarify_context:
      description: |
        Gather and clarify all policy change details, affected systems, and organizational context. Identify scope, drivers, and known gaps or constraints.
      output: >
        - Context summary table, open questions, scope diagram.
  - stakeholder_analysis:
      description: |
        Map all key stakeholders, their influence, roles, and concerns. Highlight areas of likely support, resistance, or risk.
      output: >
        - Stakeholder map/table (role, influence, concern), network diagram.
  - scenario_forecasting:
      description: |
        Construct plausible scenarios (best/worst/base case, compliance/non-compliance) post-policy change. Map likely operational, technical, and regulatory impacts.
      output: >
        - Scenario matrix/table, key assumptions, flow diagrams.
  - risk_opportunity_surfacing:
      description: |
        Surface and rank major risks and opportunities in each scenario. Include compliance, cost, workflow, technical, and reputational factors.
      output: >
        - Risk/opportunity log (item, severity, trigger, mitigation).
  - impact_summary:
      description: |
        Synthesize findings into clear, actionable impact summaries for decision-makers. Note open issues and next steps.
      output: >
        - Impact report/summary, action items, decision matrix.
  - recursive_update_audit:
      description: |
        Log all updates, context shifts, or new info. Recursively revisit prior phases if assumptions, scenarios, or stakeholder positions change.
      output: >
        - Revision/audit log (phase, change, reason, timestamp).

该管线的工程要点：

1. 每个阶段都有明确的产出物类型（表格、图、矩阵、日志），这保证了 Agent 输出可解析、可审计、可被下游阶段消费；
2. 场景预测强制覆盖多分支（best/worst/base、合规/不合规），避免单一乐观假设；
3. 风险与机会并列（risk_opportunity_surfacing），不只报忧不报喜，机会项（如"改进数据流"）同样入册并给出触发条件与缓解/放大措施；
4. 最后一阶段承担元职责：recursive_update_audit 不仅记日志，还拥有"回溯前面所有阶段"的触发权，是整套模板递归能力的落点。

五、递归审计协议：Python 伪代码中的自省循环

[recursion] 部分给出了可执行的递归控制逻辑（Python/伪代码）：

def policyimpact_agent_review(context, state=None, audit_log=None, depth=0, max_depth=5):
    """
    context: dict from context schema
    state: dict of phase outputs
    audit_log: list of revision entries
    depth: recursion count
    max_depth: adaptation limit
    """
    if state is None:
        state = {}
    if audit_log is None:
        audit_log = []

    # 1. Clarify context
    state['clarify_context'] = clarify_context(context, state.get('clarify_context', {}))

    # 2. Phased analysis
    for phase in ['stakeholder_analysis', 'scenario_forecasting', 'risk_opportunity_surfacing', 'impact_summary', 'recursive_update_audit']:
        state[phase] = run_phase(phase, context, state)

    # 3. Recursive audit/adaptation
    if depth < max_depth and needs_revision(state):
        revised_context, reason = query_for_revision(context, state)
        audit_log.append({'revision': phase, 'reason': reason, 'timestamp': get_time()})
        return policyimpact_agent_review(revised_context, state, audit_log, depth + 1, max_depth)
    else:
        state['audit_log'] = audit_log
        return state

这段伪代码的机制拆解：

• 状态累积（state）：每个阶段的结果都写入 state[phase]，后续阶段可读取先前输出，形成流水线式数据流；
• 深度上限（max_depth=5）：递归并非无限，depth < max_depth 是终止条件之一，防止因持续"发现新信息"而陷入死循环；
• 修订触发（needs_revision）：当假设、场景或干系人立场发生变化时，通过 query_for_revision 向用户/外部查询修订后的上下文，并把"改了什么、为什么改、何时改"追加进 audit_log；
• 审计日志即产物：递归终止后，state['audit_log'] 成为最终交付物的一部分，与 [examples] 中"Audit/Version Log"表格一一对应。

这一"迭代改进 + 可追溯日志"的递归模式，与仓库中的 recursive_context.py 所实现的 RecursiveContextFramework.improve(...)（带 max_iterations 上限与改进评分）在思想上同构：都是"执行 → 评估是否需要改进 → 带约束地递归"，只是 policyimpact 模板把递归对象从"文本内容"换成了"影响分析的状态机"。从源码结构看，该模板刻意将 get_time()、run_phase 等留作未定义的占位符，意味着实际落地时需要由宿主 Agent 或业务代码注入实现——这与 field_protocol_shells.py 中 ProtocolShell 提供基类、允许子类覆盖 attractor_scan 等操作的"壳 + 自定义实现"模式一致。

六、行为指令：Agent 规则与硬性红线

[instructions] 给出了注入到 System Prompt 的行为规范，是保证分析质量与可审计性的关键约束：

You are a /policyimpact.agent. You:
- Parse and clarify all policy, organization, stakeholder, and session context from the schema.
- Proceed stepwise: context mapping, stakeholder analysis, scenario forecasting, risk/opportunity surfacing, impact summary, recursive update/audit.
- DO NOT make unsupported assumptions or skip stakeholder mapping.
- DO NOT ignore regulatory or operational details unless confirmed as out of scope.
- Output all findings as Markdown—tables, headings, checklists, diagrams.
- Clearly tie scenarios, risks, and opportunities to phase findings.
- Always log changes, rationale, and contributors in the audit log.
- Surface version checkpoints after major analysis or adaptation.
- Use onboarding diagrams to help users understand the workflow and phase flow.
- Close with an audit/version log and summary of unresolved issues or recommendations.

指令中值得提炼的三条工程原则：

1. 反假设与反跳步："不得做无依据的假设，不得跳过干系人映射"——这两条 DO NOT 直接对应 Schema 中 policy_change.drivers 与 stakeholders 的完整性要求；
2. 输出即结构化：所有产出必须为 Markdown 表格/标题/清单/图，且场景、风险、机会必须与阶段发现显式挂钩（"Clearly tie..."），杜绝游离于证据链之外的结论；
3. 审计强制：每次变更必须记录"变更内容、理由、贡献者"，重大分析或适配后要输出版本检查点（version checkpoint），收尾必须附审计/版本日志与未决问题清单——这正是全模板可追溯性的最后一道保险。

七、示例输出：GDPR 场景下的全流程演示

[examples] 以 Acme Bank 遭遇 GDPR 更新为例，完整演示了六个阶段的产出形态。这是模板最直接的"照抄即用"素材：

已澄清的上下文（Clarified Context）

Policy	Org	Scope	Drivers	Effective
GDPR Update	Acme Bank	EU Ops	Regulator, DPO	2025-09-01

• Systems Affected: Data Warehouse, CRM, User Portals
• Known Gaps: Legacy data exports, vendor contracts

干系人分析（Stakeholder Analysis）

Name	Role	Influence	Concerns
J. Rivera	Legal/Privacy	High	Fines, reporting, timelines
L. Tran	IT Lead	Medium	Data flow, migration
S. Patel	Ops Manager	Medium	Workflow disruption
Vendors	External	Low	Contract renegotiation

场景预测（Scenario Forecasting）

Scenario	Impact	Key Triggers	Assumptions
Full Compliance	Minor disruption	All vendors update	On-time migration
Partial Compliance	Major disruption	Vendor lag	Data stuck in legacy
Non-Compliance	Fines, audit risk	Missed reporting	IT staff turnover

风险/机会日志（Risk/Opportunity Log）

Item	Severity	Trigger	Mitigation
Data Export Gaps	High	Vendor API lag	Accelerate migration
Staff Overload	Medium	Multiple projects	Add short-term FTEs
Improved Data Flow	Opp.	New infra deploy	Automate exports

影响汇总（Impact Summary）

• Immediate: Prioritize vendor data migration, renegotiate contracts.
• Short-term: Increase IT/project support, add compliance reporting tools.
• Next Steps: Schedule monthly audits, escalate unresolved vendor issues.

审计/版本日志（Audit/Version Log）

Phase	Change	Reason	Timestamp
Stakeholder	Added vendor mapping	Identified gap	2025-07-08 23:56 UTC
Scenario	Updated compliance risks	New legal input	2025-07-08 23:58 UTC
Summary	Created v1.1 impact report	Analysis complete	2025-07-09 00:01 UTC

示例区还附带 Onboarding/Workflow Diagram（与第二节的 ASCII 流程一致），用于让使用者一进入对话就能理解阶段流转。观察这张审计日志可发现一个细节：版本号（v1.1）与 protocolShell.v1.json 中 meta.version 的语义版本约束相呼应——模板把"影响分析报告"当作可版本化的协议产物来管理。

八、与仓库协议体系的协同：从提示词到可执行协议

policyimpact.agent 模板并非孤立存在，它与仓库的协议基础设施可以组合使用：

• 模板家族复用：同一目录下的 protocol.agent.md 提供了 fork/merge/version 的协议共创能力——当多个部门对同一政策影响结论产生分歧时，可用 protocol.agent 的"分叉合并版本化"流程管理分支结论；memory.agent.md 则可承接影响分析产出的长期沉淀（将"风险日志""审计日志"作为知识节点入库存取）。
• 协议壳执行层：仓库中 field_protocol_shells.py 提供了 ProtocolShell.from_file(...) + protocol.execute(input_data) 的可编程执行框架，并支持子类覆盖内部操作。从源码结构看，policyimpact 模板中的 JSON Schema 与 YAML 阶段定义完全可以被封装为一个自定义 ProtocolShell 的输入与过程描述，从而从"提示词模板"升级为"可校验、可执行的协议"。
• 递归控制参考：recursive_context.py 中 ContextResult 的 improvement_score 与 processing_time 字段表明，仓库在工程侧为递归改进提供了可量化的终止度量思路，可作为 policyimpact 中 needs_revision 判定的实现参考。

九、落地使用与扩展建议

直接使用三步法：

1. 将 policyimpact.agent.md 全文作为系统提示词注入支持 Markdown 渲染的 LLM 运行时（如 GPT-4o / Claude / 一般 Agentic System）；
2. 按 [context_schema] 的 JSON 结构填充本次政策变更的实际上下文（政策、组织、干系人、会话目标），必要时通过 requested_focus 限定分析维度（如只关注 compliance 或 cost）；
3. 让 Agent 按六阶段推进，并在每轮输出后核对 [examples] 中的表格形态，重点检查是否附带 Audit/Version Log。

扩展建议：

• 若要跨部门协作分析，可引入 protocol.agent.md 的 fork/merge 阶段管理分歧版本；
• 若要程序化执行与校验，可参考 field_protocol_shells.py 将本模板封装为 ProtocolShell，并参照 protocolShell.v1.json 做输入输出校验；
• 若需把分析结论长期沉淀，可对接 memory.agent.md 的知识节点/语义链接机制。

需要说明的适用前提：本模板的字段枚举（如 policy_type、influence、scope）是设计期的合理默认，实际业务若存在 Schema 未覆盖的字段（如多司法辖区叠加、供应链第三方），应在填充上下文时显式扩展 JSON 结构，并同步更新 [instructions] 中的解析规则，以保持"Schema—工作流—指令"三者的一致性。

十、结语：可审计影响分析的设计范本

/​policyimpact.agent 展示了一种值得借鉴的 Agent 模板设计范式：用 JSON Schema 固定输入边界，用 YAML 编排阶段管线，用 Python 伪代码固化递归审计控制，用 Markdown 指令约束行为红线，用完整示例兜底落地质量。它不依赖某个特定模型的能力，而是通过"结构化上下文 + 分阶段产出 + 强制审计"把政策影响分析这类高不确定性任务，转化为可复现、可追溯、可协作的工程流程——这正是 Context-Engineering 所倡导的"从提示词工程走向上下文工程设计"在合规分析场景下的具体体现。