Agentic Enterprise Architecture 90天计划

定位：面向金融零售 PM / BA / Developer，转型为 AI Solutions Architect / AI Enterprise Architect。 说明：这是新增 AI 企业架构方向扩展，不替代旧 Web3、架构、ABPA 或合约开发学习资产。

---

0. 学习目标

• 把 AI Agent 从 demo、聊天框、自动化脚本提升为企业级运营能力。
• 能用业务能力、流程编排、模型、工具、数据、安全、eval、治理、adoption 九层描述系统。
• 能围绕金融零售场景设计身份、访问、审计、数据驻留、成本、延迟、可靠性和 incident response。
• 能产出 C4、能力图、序列图、ADR、威胁模型、eval 架构、控制矩阵、runbook、adoption dashboard。
• 能评估 agent platform 的 build vs buy、供应商风险、退出策略和平台路线图。
• 能向 CTO、CRO、COO、Product VP 用不同语言解释同一套 agentic architecture。

---

1. What changed: workflow automation -> copilot -> agentic systems -> enterprise operating capability

• Workflow automation：把固定步骤自动化，例如 RPA、BPM、规则引擎、批处理脚本。

• 适合“已知问题 + 已知步骤 + 已知规则”，如对账、报表、提醒、工单路由。

• 架构重点是稳定流程、确定输入输出、异常分支和可重复执行。

• 局限是遇到模糊文本、非结构化证据、跨系统判断、多角色协作时例外处理暴增。

• Copilot：让 AI 辅助人完成任务，例如客服建议、审批 memo、BA 写需求、代码补全。

• 架构重点是上下文检索、提示词模板、权限隔离、人机界面和输出质量。

• 它提高人的速度和质量，但通常不负责任务闭环，也不承担运营状态管理。

• 局限是 AI 停在“建议层”，没有流程状态、工具行动、审批控制和运行责任。

• Agentic systems：让 AI 在明确边界内感知、计划、调用工具、执行、等待反馈并推进任务。

• Agentic 系统不是一个模型，而是 model、tool、state、workflow、policy、human approval、trace 的组合。

• 适合目标清晰但路径动态的工作，如 AML 调查、欺诈运营、合规变更影响分析。

• 架构重点从 prompt 设计转向业务能力边界、工具契约、状态编排、评估体系和治理。

• Enterprise operating capability：把 agent 能力嵌入企业运营模型，成为可管理、可度量、可审计、可持续改进的能力。

• 它进入产品路线图、流程 KPI、风险控制、审计证据、员工培训和变更管理。

• 架构师的价值不是“让 AI 很聪明”，而是让复杂业务工作更快、更稳、更可控。

• 核心转变：从“自动执行任务”到“重塑企业如何完成复杂工作”。

---

2. 目标角色画像

• PM 迁移优势：懂业务目标、用户旅程、优先级、指标和 adoption。
• BA 迁移优势：懂流程、规则、数据字典、异常分支、控制点和需求澄清。
• Developer 迁移优势：懂系统集成、API、权限、数据模型、部署、可靠性和故障排查。
• 金融零售优势：熟悉监管、审计、客户隐私、交易风险、运营流程和遗留系统。
• 需要补齐：LLM/Agent 模式、LLMOps、eval、AI 安全、供应商评估、AI 治理和高管沟通。

---

3. Architecture layers：企业级 Agentic Architecture 分层

3.1 Business capability layer

• 先描述 agent 支撑哪些业务能力，而不是先选模型或框架。
• 能力示例：客户识别、风险调查、证据收集、案件分流、建议生成、监管解释。
• 核心产物：Capability Map、能力热力图、成熟度评估、业务价值假设。
• 关键问题：哪些能力适合 automation、copilot、agentic operating model？

3.2 Process orchestration layer

• 描述端到端流程如何由 agent、系统和人共同完成。
• 覆盖事件入口、任务拆解、状态机、审批点、异常处理、补偿流程和 SLA。
• 可由 workflow engine、case management、event bus、agent runtime 或服务编排实现。
• 核心产物：BPMN、Sequence Diagram、状态转移图、异常路径图。

3.3 Model layer

• 包括 LLM、多模态模型、embedding、reranker、分类模型、传统 ML 和规则模型。
• 定义模型职责：理解、抽取、生成、分类、排序、推理、决策建议。
• 设计 model/provider portability，避免把核心业务逻辑锁死在单一模型提示词里。
• 核心产物：模型路由策略、模型能力矩阵、降级策略、模型风险登记。

3.4 Tool layer

• 工具是 agent 采取行动的边界，包括内部 API、搜索、数据库、CRM、工单、核心银行、风控平台。
• 工具契约必须定义输入、输出、权限、幂等、速率限制、错误码和审计字段。
• 金融场景要区分 read-only tool、draft tool、action tool、irreversible tool。
• 核心产物：Tool Catalog、Tool Contract、权限矩阵、工具调用序列图。

3.5 Data/knowledge layer

• 包括结构化数据、政策文档、产品手册、客户记录、案件证据、向量索引和知识图谱。
• 重点不是“上传文档做 RAG”，而是治理来源、时效、权限、引用、血缘和删除。
• 区分 authoritative source、derived knowledge、user-uploaded evidence、model-generated notes。
• 核心产物：知识架构图、RAG 数据流、数据分类分级、检索质量 eval。

3.6 Security layer

• 覆盖身份、授权、密钥、脱敏、DLP、prompt injection 防护、工具边界和输出控制。
• 原则是模型不能越权、工具不能越权、检索不能越权、行动不能越权。
• 金融零售还要处理 PII、交易数据、信贷信息、审计证据和监管保留期限。
• 核心产物：Threat Model、STRIDE/LINDDUN、安全控制设计。

3.7 Eval/observability layer

• Eval 衡量上线前后质量，Observability 提供运行时可见性。
• 覆盖任务成功率、事实准确性、引用完整性、工具正确性、成本、延迟、安全违规和人工覆盖率。
• Agentic trace 需要记录 plan、step、tool call、retrieval、memory、approval、rollback。
• 核心产物：Eval Architecture、golden dataset、red team case、trace dashboard、SLO。

3.8 Governance layer

• 定义谁能创建 agent、批准工具、上线模型、承担风险、处理 incident。
• 串联 AI policy、model risk management、third-party risk、change management、audit evidence。
• 治理必须落到流程、系统字段、审批记录和证据，不只是原则。
• 核心产物：Control Matrix、RACI、AI Risk Register、Architecture Review Checklist。

3.9 Adoption layer

• 成功不只看模型分数，还看业务团队是否真的改变工作方式。
• 设计培训、角色变化、绩效指标、反馈闭环、灰度发布和组织沟通。
• 关键问题：员工信任什么、担心什么、何时愿意把任务交给 agent？
• 核心产物：Adoption Dashboard、培训计划、使用率漏斗、行为变化指标。

---

4. Agent patterns：常见 Agent 模式

• Single-agent：一个 agent 完成检索、工具调用和输出，适合低风险、短流程、边界清晰任务。
• 风险是职责过宽、prompt 过重、流程黑箱；建议先用它验证价值，再拆控制点。
• Multi-agent：多个 agent 按角色协作，例如 investigator、policy analyst、case summarizer、reviewer。
• 风险是成本、延迟和不可控对话；只有职责边界真实存在时才拆。
• Supervisor：负责分配任务、检查结果、决定补证或人工介入，适合 case management。
• 风险是 supervisor 自身成为黑箱决策点；需要可解释、可审计和规则约束。
• Planner-executor：planner 拆解任务，executor 执行步骤，适合路径动态但目标明确的任务。
• 风险是计划漂移和结果未校验；需要可中断、可回放、可审批。
• Tool-calling：agent 通过受控工具访问系统或执行动作，是企业集成的核心模式。
• 风险是参数注入、越权、重复执行；高风险工具必须有人审、幂等键和审计事件。
• Event-driven agents：由新案件、文件上传、交易异常、政策更新等事件触发。
• 风险是重复触发、事件风暴、上下文不完整；需要 schema、去重、限流和 dead-letter queue。
• Human approval agents：agent 准备证据和草稿，人负责批准、拒绝或修改。
• 适合信贷、合规、投诉、资金动作；需要 decision packet、证据、置信度和反例。
• Background agents：后台持续监控、整理、提醒或预处理。
• 风险是静默错误、成本失控、权限漂移；需要任务队列、预算、停用机制和 runbook。

---

5. Enterprise constraints：企业落地约束

• Identity：agent 以谁的身份运行，是用户代理、服务账号、系统角色还是独立数字员工。
• Access：RBAC/ABAC 覆盖模型上下文、工具调用、数据检索、行动批准和结果查看。
• Audit：记录 prompt、检索、工具调用、人工审批、输出版本、模型版本和证据引用。
• Data residency：客户、交易、监管数据是否允许跨境、跨云或进入第三方模型服务。
• Latency：区分实时决策、准实时运营、后台分析和批处理，不同 SLA 对架构影响不同。
• Cost：成本包括 token、向量库、工具调用、人工复核、日志保留、供应商许可和 eval 维护。
• Reliability：设计超时、重试、降级、fallback model、人工接管、队列积压和幂等处理。
• Incident response：定义 AI incident 分类、上报路径、隔离措施、客户影响评估和监管沟通。
• Model/provider portability：抽象模型接口，保留 prompt、workflow、eval、trace 资产，避免专有 DSL 锁死流程。
• Change management：模型升级、知识库更新、工具变更和流程规则调整都需要版本、审批和回滚。

---

6. Financial retail use cases：金融零售 Agentic 用例

• AML investigation：收集客户画像、交易历史、关联账户、名单筛查、历史案件和政策条款。
• 输出 investigation packet、可疑模式、证据引用、缺失信息、处置建议和 SAR 草稿；监管提交必须人审。
• KYC onboarding：检查身份文件、地址证明、公司结构、UBO、PEP/sanction 命中和风险评分。
• 适合完整性检查、补件提醒、客户沟通草稿和 reviewer briefing；拒绝开户必须有规则和复核。
• Loan underwriting assistant：整合申请表、收入证明、征信、现金流、抵押物、政策和历史审批理由。
• 输出 credit memo、风险点、例外政策和补充问题；不能让模型独立作出信贷决策。
• Fraud operations：分析异常交易、设备指纹、客户行为、商户历史、规则命中和外部情报。
• 协助 case summary、调查建议、客户脚本和冻结建议；资金限制必须受阈值和审批约束。
• Customer service ops：汇总客户历史、产品条款、交易记录、投诉记录和下一步动作。
• 支持客服 copilot、工单分类、升级和回复草稿；不得承诺未经批准的赔付或法律解释。
• Wealth advisor copilot：准备客户组合摘要、风险偏好、市场材料、产品适配性和会议纪要。
• 投资建议必须受 suitability 和合规控制约束，所有建议引用批准材料和客户风险档案。
• Payment ops：分析支付失败、通道路由、拒付、对账差异、清算异常和商户投诉。
• 资金调整、商户结算和账务分录必须通过受控工具和审批。
• Compliance change management：监控监管更新、内部政策、产品条款、流程文件和系统控制。
• 输出影响分析：受影响业务、流程、系统、控制、培训和上线计划；法规解释需合规确认。

---

7. Required architecture artifacts：必须沉淀的架构产物

• C4 context/container：展示业务用户、外部系统、agent platform、数据源、工具服务和审计边界。
• Capability map：把 agent 用例映射到金融零售业务能力，标出价值、风险、成熟度和优先级。
• Sequence diagram：展示事件触发、检索、工具调用、人审、写回系统的完整链路。
• ADR set：至少 8 条，覆盖模型选择、RAG、工具权限、人审、日志、供应商、部署和回滚。
• Threat model：覆盖 prompt injection、data exfiltration、tool abuse、over-permission、jailbreak、supply-chain risk。
• Eval architecture：定义 golden dataset、自动评估、人工评估、红队测试、线上监控和质量门禁。
• Control matrix：把风险、控制、负责人、证据、频率、系统字段和审计查询关联。
• Runbook：定义 AI incident、模型降级、知识库错误、工具故障、成本飙升和人工接管。
• Adoption dashboard：跟踪使用率、节省时间、人工覆盖率、质量反馈、培训完成和业务结果。

---

8. 90-day plan：9 个十天块

Block 1：Day 1-10 重新理解企业 Agentic Architecture

• Concepts：workflow automation、copilot、agentic systems、enterprise operating capability 的差异。
• Concepts：model、tool、memory、state、policy、human approval、trace 的组合关系。
• Architecture artifact：Capability Map v1。
• 选择 AML、KYC、贷款、支付或客服，画 L0-L2 能力地图。
• 标注 value、risk、data readiness、process readiness 和 AI suitability。
• Hands-on exercise：拆一个业务流程为 trigger、task、decision、handoff、evidence。
• 写出 10 个 agent 子任务，并区分 assist、draft、act、approve。
• Interview story：先讲业务能力升级，再讲流程、模型、工具和控制。
• 30 秒版本：Agentic Architecture 是把 AI 嵌入企业运营能力，而不是加一个聊天入口。
• 2 分钟版本：从能力图到流程编排，再到模型、工具、控制、eval 和 adoption。

Block 2：Day 11-20 C4 与企业边界

• Concepts：C4 Context 表达用户、监管、外部数据源、内部系统和 AI 平台边界。
• Concepts：Container 拆分 agent runtime、workflow engine、tool gateway、RAG service、eval service、audit log。
• Concepts：系统边界决定责任边界，责任边界决定风险和审计方式。
• Architecture artifact：C4 context/container。
• Context 图至少包含业务用户、风险团队、合规团队、核心系统、第三方模型服务和审计系统。
• Container 图至少包含 8 个容器和 5 个外部系统。
• Hands-on exercise：用 draw.io、Mermaid 或 PlantUML 画图，并写 1 页架构说明。
• Interview story：向 CTO 解释系统边界、集成复杂度、可靠性和可演进性。
• 30 秒版本：C4 让 AI 系统从 demo 变成可评审、可交付的企业架构。
• 2 分钟版本：解释为什么需要 runtime、tool gateway、audit log 和 eval service 分离。

Block 3：Day 21-30 流程编排、工具调用与序列设计

• Concepts：Agentic workflow 与传统 BPM/RPA 的区别。
• Concepts：planner-executor、supervisor、human approval 的组合方式。
• Concepts：Tool contract 的输入、输出、权限、幂等、超时、错误和审计。
• Architecture artifact：Sequence Diagram。
• 序列图必须包含事件触发、agent plan、RAG retrieval、3 次工具调用、人工审批和审计写入。
• 标出同步调用、异步事件、失败分支和人工接管点。
• Hands-on exercise：设计 Tool Catalog，列出 read、draft、action 三类工具。
• 为每个 action tool 设计 approval rule、idempotency key 和 audit event。
• Interview story：解释如何防止 agent 调错工具、重复执行或绕过审批。
• 30 秒版本：企业 agent 的行动能力必须通过工具契约治理。
• 2 分钟版本：用工具分级、权限、幂等、审批和 trace 说明安全执行链路。

Block 4：Day 31-40 模型层、知识层与 RAG 架构

• Concepts：LLM、embedding、reranker、分类模型、规则模型在企业场景中的分工。
• Concepts：RAG 的知识治理：来源、时效、权限、引用、删除和版本。
• Concepts：prompt、policy、tool schema、retrieval config 都是架构资产。
• Architecture artifact：ADR set v1。
• 写 8 条 ADR，覆盖模型路由、RAG、向量库、reranker、工具网关、日志、人审、供应商。
• 每条 ADR 包含背景、决策、替代方案、后果和复盘触发条件。
• Hands-on exercise：建立小型知识集，包括政策、流程、案例、FAQ。
• 写 20 条检索测试问题，并记录 expected source、required citation 和 permission tag。
• Interview story：解释为什么 RAG 不是上传文档，而是知识生命周期管理。
• 30 秒版本：Agent 的知识必须可追溯、可更新、可授权、可评估。
• 2 分钟版本：用 authoritative source、version、citation、permission filter 说明知识架构。

Block 5：Day 41-50 安全、隐私、威胁模型与控制矩阵

• Concepts：prompt injection、data exfiltration、tool abuse、jailbreak、model leakage。
• Concepts：金融隐私风险：PII、PCI、交易记录、信贷信息、投诉记录、监管材料。
• Concepts：Threat modeling for agents：资产、入口、信任边界、攻击路径、控制点。
• Architecture artifact：Threat Model + Control Matrix。
• 用 STRIDE 分析 agent runtime、RAG、tool gateway、audit log、human approval。
• 输出不少于 15 条控制，包含 owner、evidence、frequency、system field。
• Hands-on exercise：设计 10 个红队测试，包括恶意文档、越权查询、假客户请求和工具参数注入。
• 每个测试定义 expected block、expected log 和 reviewer action。
• Interview story：向 CRO 解释 agent 风险靠控制链和证据链管理。
• 30 秒版本：我们把 agent 当作高权限数字操作员管理。
• 2 分钟版本：围绕身份、访问、审计、人审和 incident response 说明三道防线。

Block 6：Day 51-60 Eval architecture 与 observability

• Concepts：传统 UAT 不足以验证 agentic systems。
• Concepts：离线 eval、线上 eval、人工评审、红队测试和业务结果评估。
• Concepts：Agent trace 包括 plan、step、tool call、retrieval、approval、output、cost、latency。
• Architecture artifact：Eval Architecture。
• 设计 eval pipeline：golden dataset、scorer、human review、release gate、monitoring。
• 定义不少于 12 个指标，覆盖 quality、safety、cost、latency、adoption。
• Hands-on exercise：为 chosen use case 写 30 条测试案例。
• 每条案例写 expected answer、required citation、allowed tools、failure condition。
• Interview story：解释 agent 上线不是一次验收，而是持续评估和运行监控。
• 30 秒版本：没有 eval 的 agent 不能进入企业关键流程。
• 2 分钟版本：讲清 golden set、red team、release gate、runtime trace 和业务 KPI 闭环。

Block 7：Day 61-70 Build vs buy、供应商评估与平台架构

• Concepts：agent platform 能力：runtime、workflow、tooling、RAG、eval、guardrail、observability。
• Concepts：build vs buy 维度：差异化、监管、数据敏感度、集成复杂度、人才、时间、成本。
• Concepts：供应商风险：锁定、数据使用、审计能力、区域部署、SLA、退出机制。
• Architecture artifact：ADR set v2 + Vendor Evaluation Scorecard。
• 设计供应商评分表，覆盖安全、合规、集成、eval、可观测、成本、可移植、支持。
• 写 3 条关键 ADR：自建/采购、单模型/多模型、集中平台/业务域平台。
• Hands-on exercise：纸面评估云厂商 AI 平台、企业 agent 平台、开源 agent framework。
• 写出 preferred option、fallback option、exit strategy。
• Interview story：向 CTO 解释为什么“买平台”不等于“完成 AI 转型”。
• 30 秒版本：平台采购解决基础能力，企业架构解决业务边界、控制和运营。
• 2 分钟版本：用差异化能力、监管要求、集成成本和供应商退出说明决策逻辑。

Block 8：Day 71-80 Runbook、incident response 与 adoption dashboard

• Concepts：AI incident 包括错误建议、越权访问、工具误调用、知识库错误、成本飙升、模型降级。
• Concepts：Runbook 要让运营、工程、安全、合规和业务 owner 都知道下一步动作。
• Concepts：Adoption 不是登录次数，而是行为改变和业务结果。
• Architecture artifact：Runbook + Adoption Dashboard。
• 写 6 类 incident 的触发条件、检测信号、处置步骤、沟通模板和复盘字段。
• Dashboard 覆盖 usage funnel、time saved、override rate、quality feedback、business KPI。
• Hands-on exercise：模拟一次 agent 错误建议事件。
• 从检测、隔离、通知、修复到复盘，写 1 页 post-incident review。
• Interview story：向 COO 解释 agent 落地是运营模式变更。
• 30 秒版本：价值来自流程、角色、指标和反馈闭环一起改变。
• 2 分钟版本：结合 runbook、培训、dashboard 和运营 KPI 说明规模化路径。

Block 9：Day 81-90 Capstone、作品集与高管叙事

• Concepts：Capstone 不是功能 demo，而是企业级架构包。
• Concepts：同一套材料要服务 CTO、CRO、COO、Product VP 四类受众。
• Concepts：作品集展示你能把模糊业务问题变成可落地、可治理、可评估的系统。
• Architecture artifact：Capstone Architecture Pack。
• 汇总 C4、Capability Map、Sequence Diagram、ADR、Threat Model、Eval Architecture、Control Matrix、Runbook、Adoption Dashboard。
• 补充 8 页以内 executive deck 和 1 页 resume project summary。
• Hands-on exercise：20 分钟讲 capstone，再用 20 分钟接受四类高管追问。
• 录音或写逐字稿，复盘表达是否过度技术化或缺少业务结果。
• Interview story：讲清如何从业务能力出发设计 agentic enterprise capability。
• 30 秒版本：我设计的不只是 agent，而是可控、可评估、可运营的企业 AI 能力。
• 2 分钟版本：按业务能力、流程、模型工具、数据知识、安全控制、eval、治理和 adoption 展开。

---

9. Build vs buy and vendor evaluation for agent platforms

9.1 何时倾向 Buy

• 需要快速验证价值，平台能力覆盖基础需求。
• 公司缺少 agent runtime、LLMOps、eval、observability 和安全工程能力。
• 场景不属于核心差异化能力，如内部知识问答、文档摘要、低风险客服辅助。
• 供应商能满足数据驻留、审计、SLA、权限、日志和退出机制。

9.2 何时倾向 Build

• 场景是核心竞争能力，如风控、信贷、财富顾问、支付路由、合规运营。
• 需要深度集成遗留系统、内部规则、专有数据和复杂审批。
• 对数据、审计、可解释、模型路由、成本控制和监管证据有强要求。
• 公司已有平台工程、数据工程、安全工程和 MLOps/LLMOps 基础。

9.3 混合策略

• Buy 基础模型和云基础设施，Build 工具网关、权限、eval、审计和业务工作流。
• Buy agent platform 做低风险场景，Build 关键流程的受控执行层。
• Buy RAG/搜索能力，Build knowledge governance、数据分类和引用验证。
• 先项目化落地，再抽象 shared agent services。

9.4 Vendor evaluation scorecard

---

10. How to explain agentic architecture to CTO/CRO/COO/Product VP

• To CTO：讲架构边界、平台能力、集成复杂度、可靠性、可观测性、可移植性。
• 关键图是 C4、Sequence Diagram、Model/Tool/Data Architecture；关键问题是降级、回滚、成本和 SDLC。
• 30 秒说法：我们把模型能力封装为可治理的企业服务，并保留多模型和供应商退出能力。
• To CRO：讲风险分类、控制矩阵、审计证据、人审、模型风险和第三方风险。
• 关键图是 Threat Model、Control Matrix、Human Approval Flow、Incident Runbook。
• 30 秒说法：我们把 agent 当作高权限数字操作员管理，关键动作都有权限、审批和证据链。
• To COO：讲流程效率、运营 SLA、人工覆盖率、异常处理、培训和组织 adoption。
• 关键图是 Process Orchestration、Runbook、Adoption Dashboard、Operating Model。
• 30 秒说法：重复取证、整理和草稿工作交给 agent，人专注判断、例外和客户影响。
• To Product VP：讲用户价值、产品体验、路线图、差异化、指标、实验和 adoption。
• 关键图是 Capability Map、User Journey、Value Metrics、Release Roadmap。
• 30 秒说法：从高频痛点和高价值流程切入，用可评估的 agent capability 提升体验和运营结果。

---

11. Failure modes and anti-patterns

• Chatbot washing：把 AI 项目包装成 agent，但没有工具、状态、控制和闭环。
• Prompt-only architecture：核心业务逻辑藏在 prompt 中，没有版本、测试、审计和 ADR。
• Tool free-for-all：agent 工具过多，没有权限分级、幂等和审批。
• RAG dumping ground：文档全量上传，不治理来源、权限、时效、引用和删除。
• No eval, only vibes：只看 demo，不建立 golden dataset、红队和上线门禁。
• Over-agentification：简单规则或固定流程也强行用 agent，增加成本和不确定性。
• Human approval theater：表面有人审，但不给证据、反例、置信度和足够判断时间。
• Invisible cost curve：没有 token、工具调用、日志、人工复核和评估成本预算。
• No incident path：agent 出错后不知道停哪个功能、通知谁、如何隔离影响。
• Vendor lock-in by workflow：流程、prompt、数据和工具绑定在供应商专有平台。
• Model as decision maker：让模型直接做信贷、冻结、拒绝开户、监管解释等高风险决策。
• Audit afterthought：上线后才补审计字段，导致无法解释历史输出。
• One giant agent：所有职责塞进一个 agent，难以测试、授权、优化和复盘。
• Ignoring operations：只交付技术方案，不设计培训、反馈、runbook 和 adoption 指标。
• No kill switch：没有禁用 agent、禁用工具、切换模型、切回人工流程的机制。

---

12. Capstone options beyond AML

• KYC onboarding agentic operating model：从资料收集到 EDD 分流，重点是文件证据、UBO、PEP/sanction、人审。
• Loan underwriting assistant：生成 credit memo、政策例外、补件问题和审批包，重点是公平性和解释性。
• Fraud operations case copilot：聚合异常交易、设备、客户、商户和规则证据，生成处置建议。
• Payment exception resolution agent：处理支付失败、拒付、对账差异和商户沟通，重点是资金动作控制。
• Customer complaint triage and remediation：分类投诉、总结证据、匹配政策、生成补救建议。
• Compliance change impact agent：监控法规变化，映射到产品、流程、系统、控制和培训。
• Wealth advisor meeting copilot：准备客户摘要、组合变化、风险适配、批准材料和会议纪要。
• Collections strategy assistant：为贷后催收生成客户分层、沟通策略、困难证明和合规话术。
• Retail inventory anomaly agent：分析库存差异、门店损耗、供应链延迟和补货建议。
• Merchant risk review agent：聚合商户交易、退款、拒付、行业风险和尽调材料。
• Product policy QA agent：回答政策问题，提供引用、版本和变更记录。
• AI governance cockpit：跟踪企业 AI use case 风险、eval、控制、adoption 和 incident。

---

13. 每日学习节奏

• 60 分钟概念学习：读论文、厂商文档、监管指引、架构案例。
• 60 分钟架构建模：画图、写 ADR、补控制矩阵或 eval case。
• 60 分钟 hands-on：构建小 prototype、测试 RAG、设计 tool schema、跑 eval。
• 30 分钟金融零售映射：落到 AML、KYC、贷款、支付、客服或合规。
• 30 分钟面试表达：写 30 秒版本和 2 分钟版本，并准备 3 个追问。

---

14. 作品集结构

• 01 Executive Summary：业务问题、目标能力、关键价值、风险边界。
• 02 Business Capability Map：能力图、热力图、优先级。
• 03 C4 Architecture：Context、Container、关键系统边界。
• 04 Process and Sequence：流程编排、序列图、人审路径。
• 05 Model/Tool/Data Architecture：模型、工具、知识和数据治理。
• 06 Security and Controls：威胁模型、控制矩阵、审计证据。
• 07 Eval and Observability：eval pipeline、指标、trace、SLO。
• 08 Operating Model：runbook、RACI、incident response、adoption dashboard。
• 09 Build vs Buy：供应商评估、ADR、路线图和退出策略。

---

15. 面试故事模板

• 背景：金融零售场景中存在什么复杂流程和业务痛点。
• 约束：监管、隐私、审计、遗留系统、成本、延迟、组织 adoption。
• 任务：把 AI 从辅助建议升级为可运营的 enterprise capability。
• 行动：用能力图定范围，用 C4 定边界，用序列图定流程，用 ADR 定决策。
• 控制：用威胁模型、控制矩阵、人审、eval、trace 和 runbook 控制风险。
• 结果：给出效率、质量、风险、成本和 adoption 指标。
• 反思：哪些地方不该用 agent，哪些地方需要先做数据、流程或控制治理。

---

16. 90天结束后的能力验收

• 能在 10 分钟内解释 agentic architecture 与传统自动化、copilot 的区别。
• 能画出金融零售 agentic solution 的 C4 Context/Container。
• 能把复杂运营流程拆成 agent、tool、human approval 和 system action。
• 能写出不少于 8 条高质量 ADR。
• 能完成 threat model 和 control matrix，并解释给 CRO。
• 能设计 eval architecture，并定义上线门禁和运行监控指标。
• 能写 runbook，覆盖 AI incident、降级、回滚和人工接管。
• 能做 build vs buy/vendor evaluation，并提出退出策略。
• 能用 CTO/CRO/COO/Product VP 四种语言讲同一套架构。
• 能完成一个 capstone，并整理成面试和作品集材料。