占彬

AI架构师 / 数据架构师

个人背景

微信：bin668085 | 76626123@qq.com

GitHub: github.com/bin448482 — 开放 RAG 知识资产化与 AI 数据治理自动化项目源码，可使用 AI 工具分析。RAG 知识构建与数据治理自动化均已形成工程成果；相关设计取舍及方法论依据，可参见本简历引用的论文与标准。

技能总览

AI Native 是我最根本的工作方式——从架构决策到代码实现，AI 作为默认协作伙伴嵌入每个环节，而非事后辅助工具。AI 时代具体技术技能的半衰期急剧缩短，真正稀缺的是三种能力：用第一性原理定义问题边界（Critical Thinking），设计协议与编排机制让异构能力高效协同（Harness），以及对端到端交付结果承担 Owner 责任（Responsibility）。

Agent 与 Harness 的工程定义：调用了 LLM 的 API 不等于做了 Agent。Agent 必须同时具备三个要素——可调用的 tools（工具执行与环境反馈）、observe-act 循环、由模型自主判断的终止条件，三者缺一不可。仅调用 LLM 完成单次生成的系统属于 LLM 应用，不属于 Agent；用任何框架搭出来的固定流程 DAG，本质仍是 workflow，也不是 Agent——框架本身不决定是否构成 Agent，三要素是否齐备才是判别标准。Harness 是围绕这三个要素建立的工程约束层——工具协议、循环边界、终止判断、状态恢复、审计追溯从业务逻辑中剥离为独立基础设施，让 Agent 行为可观测、可约束、可回归。Agent 决定「做什么」，Harness 决定「在什么约束下、可被观测地做」。

过去两年主导企业级 Agentic AI 平台从零到一的经历，正是这一理念的实践——不止于调用模型或集成工具，而是在 Agent 身份体系、Skill 标准化接口、多 Agent 协作模式等层面建立可复用的架构契约，并在此基础上抽象出通用 Pipeline Harness 协议，将流水线调度从业务逻辑彻底解耦为独立基础设施。

同时具备跨国企业数据湖仓架构与治理实战经验，熟悉 Azure 全栈云服务与合规数据同步方案，能独立闭环全栈项目从需求到交付的完整链路。持有 Microsoft Azure Solutions Architect Expert 认证。

开发框架与AI生态：熟练 Python（LangChain、LangGraph、ChromaDB、Pydantic、FastAPI），熟练 C#（.NET Core、Entity Framework），掌握 TypeScript/JavaScript（React、Next.js、Angular、React Native/Expo），掌握 Java（Spring Boot），了解 Go。

数据与云平台：熟练 Azure（App Service、Functions、Databricks、Data Factory、SQL Database、Cosmos DB、Storage、Key Vault），掌握 SQL/Databricks 数据管道与OLAP维度建模，熟悉阿里云 DataWorks、MaxCompute、Data Agent 的元数据读取、数据资产画像和受控执行边界，了解 Spark、HDFS、Hive。

AI/LLM：熟练 OpenAI/Azure OpenAI API 集成与提示工程，掌握 Agent 工程化（工具调用与环境反馈、observe-act 循环、模型自主终止判断三要素的工程实现）、RAG 检索增强生成（向量检索＋相似度阈值护栏）、向量数据库（ChromaDB）、基于状态图的多步骤工作流编排（LangGraph）、多Agent并行任务分发与结果聚合、Agent可靠性护栏（重试、超时、防自循环、结构化输出校验）、Data Agent Skill 设计（计划先行、证据链、人工确认、SQL审批门禁）、LLM应用架构设计、Prompt版本管理与A/B实验框架。

DevOps与基础设施：掌握 Docker、Nginx、CI/CD、Prometheus、Grafana、JSONL日志审计、Azure Key Vault密钥管理、JWT认证、API限流。

分布式架构与微服务：掌握 服务拆分与领域边界划分、API网关与统一入口设计、异步消息通信（消息队列解耦、事件驱动架构）、幂等设计与防重机制（唯一键/Token去重/状态机幂等）、分布式事务最终一致性（Saga/TCC/补偿机制）、服务注册发现与负载均衡、配置中心与动态路由、分布式链路追踪与可观测性、熔断降级与限流策略。

工程实践：熟练 设计模式（工厂、适配器、模块化架构）、配置驱动开发、单元/集成/性能测试、版本控制与代码规范、数据血缘追踪与元数据管理、数据产品画像、物理表到逻辑业务对象归并、通用Pipeline协议与任务状态机设计。

认证

• Microsoft Certified: Azure Solutions Architect Expert
• Microsoft Certified: Microsoft Azure Administrator
• Scrum Master

工作经历

2026.06 – 至今 richemont AI数据治理项目

AI / 数据治理架构顾问

主要职责:

• 围绕企业数据模型迁移场景，设计元数据级差异分析与下游影响评估方法，将源系统、ODS、CDM、ADS/BI消费层之间的粒度、字段、枚举、口径和影响范围纳入同一分析框架
• 建立个人Dev辅助链路与客户内部受控链路的边界：个人环境只沉淀方法、模板、脚手架和脱敏样例；真实元数据读取、SQL执行和影响判断保留在内部 DataWorks / MaxCompute / Data Agent 环境中完成
• 设计 Data Agent 原生 Skill 的执行契约，将流程拆分为元数据细节读取、业务对象归并、结果包输出三个阶段，并定义计划先行、证据链、置信度、人工确认点和SQL审批门禁
• 开发和验证元数据读取、数据产品画像、治理质量评估、DataWorks受控验证和表标签建议等Skill/脚手架，使AI辅助治理从一次性问答转化为可审计、可回放、可继续处理的工程流程
• 将工作日志自动化方法用于项目跟踪，把分散的日报、会议记录和执行记录整理为具有生命周期的任务状态，持续维护进展、风险、待确认问题和下一步动作

主要业绩:

• 形成可迁移到内部 DataWorks / MaxCompute / Data Agent 环境的元数据差异矩阵、下游影响评估、数据产品画像、表标签建议和验证SQL草案输出契约
• 把物理表清单提升为业务对象画像，要求归并规则、证据来源、置信度和待确认问题同时输出，避免将每张物理表机械翻译为一个业务对象
• 建立“只读元数据优先、聚合SQL审批、生产资产写回需二次确认”的安全边界，使AI辅助数据治理能在合规约束下逐步推进
• 通过Promptfoo、结构化校验和黄金样例回归，验证Skill输出的字段、报告状态、逻辑对象归并和安全边界，降低后续迭代中的输出漂移风险
• 开发基于静态SQL证据的分层字段血缘追溯与审计工具：先将物理表、外部表、CTE、派生查询和集合分支抽象为Dataset Node，构建集合依赖图并做上游DFS；再在scope和节点路径约束下执行字段DFS，保留歧义候选、外部终点和人工writer绑定审核

2026.01 – 2026.06 迅傲

AI架构师

主要职责:

• 架构分层：将业务团队在Agent身份定义、能力封装和调用协议上的共性需求抽象为Application→Agent→Skill→Infrastructure四层架构，以分层契约约束各层边界，消除跨场景重复建设
• Agent组成模型：将Agent拆分为Persona（角色职责）、Memory（上下文记忆）、Skills（能力集）三个独立维度，每维度独立配置、独立复用——新Agent按需组合，无需重新定义完整行为模型
• Skill接口标准化：将业务能力抽象为RAG/BI/Generator/Action/Workflow五种Skill模板，统一execute接口——各业务线按同一协议接入，消除API风格差异带来的适配成本
• 路由与编排边界：设计Agent Router作为平台调度中枢，统一管理身份识别、意图理解、Agent分配和对话历史——各业务Agent复用同一套身份与路由基础设施；设计Skill Router抽象串行/并行/条件/循环四种编排模式——多Skill协同通过声明式配置完成，编排逻辑与业务代码解耦
• Agent协作模式：设计主从、并行、链式三种多Agent协作模式——复杂任务按业务语义拆解后分配到对应Agent组合，协作逻辑不耦合在单个Agent内部
• 并行执行落地：把Skill Router的并行编排模式落地为具体的多LLM并行执行——单次业务请求中相互独立的LLM调用按bounded-concurrency工作池并行发起（最大并发度可配置，按LLM提供方限流上限调整），典型场景为RAG知识构建Map-Reduce阶段的per-batch页摘要与per-category归并；吞吐与时延按可观测指标对比，避免「并行编排」只停留在模式声明
• 并发基础设施蓝图：沉淀平台基础设施层的多LLM并发架构蓝图（主干）——API Gateway统一入口 + 按角色分优先级的MQ队列削峰填谷 + 动态扩缩容Worker Pool异步消费，并行调用内部LLM平台（vLLM/Ollama/自研模型）与外部LLM API（OpenAI/Claude等多provider），覆盖「敏感数据走内部、高质量需求走外部」的混合编排场景；作为架构设计材料独立沉淀，可作为同类企业场景的基础设施蓝图复用
• 可靠性与智能路由：沉淀平台基础设施层的多LLM并发架构蓝图（可靠性侧）——调用侧封装熔断器（closed/open/half-open三态机+恢复窗口）、指数退避＋抖动的重试策略，以及按数据敏感度、任务复杂度、成本优化、角色指定四类策略的智能路由，单一provider抖动不会传导为整体不可用
• Plan-Graph工程化：推动复杂任务的plan-graph化拆解——大任务以LangGraph状态图组织为可观测、可重入的子节点链路（典型如知识入库的六节点流水线「准备→Map→合并→Reduce→Overview→校验」、JD匹配从单段大prompt拆为「区域识别→区域内匹配」两段），降低单节点prompt token规模、隔离跨区域的无关候选噪声并便于按节点回放
• Prompt工程化：建立prompt工程化体系——所有prompt集中至可版本化的注册表（模板与调用代码解耦）；通过结构化输出schema、JSON验证节点和黄金问题集回归评测（基于Promptfoo等框架），把「调prompt」从经验式调试转化为可对比质量/成本/时延的工程化迭代
• 复用性验证：以solution_advisor（运营场景）和candidates（招聘场景）两个业务Agent验证平台复用性——两场景共享同一组Skill模板与Router配置，新增业务Agent仅需补充Persona与Memory，不重写Skill实现，新场景沿既有能力框架扩展
• 开发者Skill封装：将公司内反复出现的非平台型工作流沉淀为可分发的Claude Code Skill包（SKILL.md frontmatter + scripts/ + references/ + agents/）——区别于平台内的RAG/BI/Generator/Action/Workflow五种Skill模板（Agent调用的能力契约），Claude Code Skill是开发者侧可加载的工作流封装
• 标准化Skill交付：交付solution-quote（售前方案与报价生成，覆盖从邮件、会议纪要、非结构性文档等输入采集到证据可追溯的方案与报价交付）和ruflo-delivery（设计说明驱动的交付流水线，含Gate A/B审批与runs/delivery真值文件管理）两个标准化Skill

主要业绩:

• 明确平台内 Agent 与 Harness 的工程边界——Agent 承担「tools + observe-act 循环 + 模型自主终止」三要素，Harness 承担调度、状态、审计、回归四层工程约束；候选人评估系统作为 Harness 工程范例，编排外部 AI CLI 作为 Agent 执行者，而非自建 Agent
• 同一套Skill接口与协作编排在运营和招聘两个场景中得到复用验证
• RAG知识资产化引擎将售前咨询从检索零散材料转变为调用结构化知识资产，对外输出口径趋于一致，知识沉淀随使用持续积累
• 候选人评估系统从Agent原型演进为通用Pipeline Harness平台——TaskManifest状态机、多JD矩阵、Supervisor监督、回归框架等核心能力与业务场景解耦，流水线调度可复用到其他数据处理场景
• 把公司内反复出现的非平台型工作流沉淀为可分发的Claude Code Skill包——售前方案与报价生成、设计说明驱动的交付流水线均按SKILL.md规范封装，配套scripts和references可在不同仓库间复用，开发者按skill discovery机制自动加载，无需重复梳理同类工作流

2023.06 – 2025.09 Zoetis

数据架构师

主要职责:

• 中国区NGSE数据架构从零搭建——与全球和本地业务方逐一对接需求，将各方数据诉求转化为湖仓分层架构和端到端数据链路（原始层→特征层→标签层→模型层）
• 数据出境方案的核心不是二元判断，而是分类治理：需境内重建的、脱敏后可合规跨境的、聚合后不影响分析价值的，按类别设计分层治理与同步策略，不机械照搬全球模型
• 全球与本地对同一概念的定义存在差异——建立指标与特征映射体系，配置字段字典和版本管理，确保跨区域口径一致
• 为算法和策略团队搭建稳定的数据服务接口，约定特征更新频率和调用方式；优化核心链路计算与存储，控制大表扫描和重复计算
• 搭建覆盖销售机会、拜访转化、处方趋势的评估框架，支撑业务方持续追踪NGSE效果

主要业绩:

• 中国区NGSE湖仓与AI数据底座从零到一上线，全球销售方法论以结构化方式落地本地
• 核心销售与推荐数据的产出链路稳定运转，为模型训练和线上推荐提供可靠输入
• 全球与本地关键商业指标的口径对齐和特征映射生效，跨区域效果评估基于统一的指标定义
• 在数据出入境合规框架内，通过分层与跨境同步策略，本地推荐能力与全球方法论保持同步演进
• 业务团队可按区域、产品线持续看到NGSE带动的变化

2016.11 – 2023.02 PWC

高级技术顾问（解决方案架构）

主要职责:

• 多国MDM数据统一进入一个平台——首先梳理各国口径差异，再定义统一的主数据标准和映射规则
• ETL链路全程可追溯——从原始层到整合层再到应用层，每一层的数据边界在审计时均可回溯
• 搭建Web数据门户供业务和审计方自助查询——按角色配置权限和视图分层，减少对人工取数的依赖
• 建立数据质量监控体系——覆盖完整性校验、一致性校验和跨区域对账，异常早于业务感知暴露
• 将审计要求转化为可配置的技术方案——数据血缘、操作日志、报表留存全部按审计标准实现

主要业绩:

• 多国MDM数据统一为标准模型后，主数据质量和完整性有了可靠基线
• 可追溯ETL链路加血缘展示，数据问题定位不再依赖代码审查和日志排查
• 批处理和查询逻辑优化后，主报表刷新更加稳定，高峰期不再互相抢资源
• Web门户让客户和审计方自助取数，流程和审计信息统一交付

2010.10 – 2016.10 HP

.NET开发 & Scrum Master

主要职责:

• 带领团队并行推进接口开发、ETL和测试三条工作线，协调资源分配与交付节奏
• 设计LMS系统架构，负责SABA培训系统API对接和实时数据同步方案
• 使用Informatica构建ETL层——负责计划任务配置、映射关系梳理和数据流开发
• 开发接口监测服务，主动发现异常，缩短问题定位时间

主要业绩:

• 成功交付LMS的ODS系统，支撑HP培训与外部订单管理
• 建立稳定的SABA培训系统API接口和实时数据同步机制
• 明确接口开发、ETL和测试三条工作线的职责边界，建立稳定的并行交付节奏
• 通过优先级管理与迭代节奏控制，实现每两周一个版本的持续交付

项目经验

2026.06 – 至今 独立项目合作

项目名称：企业数据平台迁移与 AI 数据治理自动化（脱敏版）

AI / 数据治理架构顾问

项目描述： 为大型集团的数据平台迁移与数据资产治理场景提供AI与数据治理架构支持。项目背景不是简单的字段搬迁，而是在多层数仓结构中识别源系统、ODS、CDM、ADS/BI消费层之间的元数据差异、模型复用关系和下游影响范围，并将Data Agent引入为受控治理入口。

解决的问题： - 传统迁移分析容易停留在字段名相似度匹配，无法解释粒度、枚举、口径、业务对象和下游消费影响 - 敏感数据、生产资产和权限操作必须留在客户内部环境，个人Dev环境只能承载方法、模板、脚手架和脱敏样例 - Data Agent 如果只输出阅读版报告，后续很难继续进入SQL验证、质量规则候选、表标签建议、Data Map注释建议和人工确认流程

核心设计：

第一层是双链路隔离：客户内部链路负责DataWorks / MaxCompute / Data Agent执行，个人Dev链路只负责方法设计、脚手架开发、脱敏样例验证和输出契约迭代。AI只处理元数据、聚合摘要、SQL草案和抽象规则，不接触行级数据或生产敏感信息。

第二层是Data Agent Skill 三阶段协议：先读取字段级元数据细节，再按命名模式、字段组合、血缘和业务键归并为逻辑业务对象，最后输出结构化结果包。每一阶段都有明确输入、输出和职责边界，避免Agent在同一步里同时读取、推断、渲染和写回。

第三层是可审计治理输出契约：结果包包含运行状态、业务画像、逻辑对象映射、证据清单、待确认问题、验证SQL草案、质量规则候选、标签建议和可选阅读版报告。SQL默认只生成草案，聚合执行和生产资产写回都需要人工确认。

第四层是任务状态管理：将工作日志自动化Skill用于项目跟踪，把分散记录转化为active / closed / pending confirmation三类任务状态，持续维护当前阶段、进展、风险、阻塞、证据和下一步动作，减少每次恢复上下文时的人工重建成本。

第五层是分层静态数据血缘治理：固定SQL快照和哈希后，先抽象数据集合并构建Dataset Node依赖图，沿目标节点向上游DFS；再在已证明的节点路径和SQL scope内追溯字段表达式。对未限定列、星号投影、动态关系和多writer等无法静态唯一证明的情况保留歧义证据，并通过人工审核形成可重复、可追溯的治理结论。

技术亮点： - 基于 DataWorks OpenAPI / MCP / MaxCompute 元数据能力设计只读采集路径，输出面向元数据差异矩阵和下游影响评估 - 将物理表到逻辑业务对象的归并规则写入Skill契约，要求header/line、主维/子维、过程事件和汇总视图按业务粒度表达 - 为Data Agent输出增加状态文件、证据manifest、pending questions和SQL approval gate，使结果可以被继续审查、执行和追溯 - 通过Promptfoo、结构化校验和黄金样例评估，验证逻辑对象归并、报告状态、安全边界和输出字段不在迭代中回退

业务价值： - 把数据迁移前期分析从人工逐表理解推进为可复用的AI辅助分析方法，分析结论带有证据、置信度和人工确认点 - 将DataWorks / MaxCompute元数据能力与Data Agent的交互能力结合，形成可在内部环境运行的受控数据治理流程 - 在不带出真实数据的前提下，个人Dev环境仍能持续迭代方法、模板和Skill契约，再迁移回内部环境验证

技术成果： - 沉淀Data Agent原生数据产品画像Skill、表标签建议Skill、元数据读取脚手架、数据治理画像分析与质量评估链路 - 建立元数据差异矩阵、CDM/下游影响评估、逻辑对象映射、验证SQL草案和任务状态跟踪的脱敏模板体系 - 开发SQL驱动的字段血缘追溯与审计工具，采用Dataset Node图、节点级DFS、字段级DFS、逻辑路径标识和分支感知去重，支持可重复生成、变更追踪与回归核验

方法论参考：以W3C PROV-DM的Entity / Activity / Agent模型表达数据集合、SQL加工与责任主体；节点级追溯参考Cui & Widom（VLDB 2001）Lineage Tracing for General Data Warehouse Transformations，字段来源与加工解释参考Cheney、Chiticariu与Tan（2009）Provenance in Databases: Why, How, and Where。

迅傲

项目名称：企业级Agentic AI平台

AI架构师

项目描述： 主导公司级Agentic AI平台的总体架构规划与落地，围绕统一入口、数字员工身份体系、Skill标准化接口和多Agent协作机制构建可复用的能力底座，在运营和招聘两条业务线分别交付了RAG知识资产化引擎和智能候选人评估系统，验证了平台能力在不同业务场景中的复用价值。

平台层面解决的问题： - 业务团队推进Agent应用时，在身份定义、能力封装、调用协议和协作逻辑上存在重复建设，平台能力难以跨场景沉淀 - 不同业务场景对数据安全、执行审计、结果追溯和本地化运行都有较高要求，缺乏统一治理框架时，后续扩展成本高、交付口径不一致

平台层面的做法： 核心思路是将Agent建设中反复出现的共性能力抽象为公共层——四层架构管理身份和能力边界、标准化Skill接口管理能力接入、双Router管理调度和编排。两个业务Agent（solution_advisor、candidates）在同一个平台上复用这套契约，验证了「一次底座建设、多场景接入」的复用模式。平台级治理能力（运行清单、结构校验、追溯校验）保证执行结果可审计、可复盘。

落地场景一：RAG知识资产化引擎（运营业务Agent）

解决的问题： - 解决方案材料以零散非结构性内容形式分散沉淀，传统切片方式容易丢失上下文关联，导致检索召回噪声大、回答碎片化、溯源困难 - 售前咨询场景对专业性和一致性要求很高，需要把原始材料转化为可复用、可追溯的知识资产，而非依赖人工检索零散材料

项目定位与 Agent 边界： 在线问答链路是一个 RAG Agent——具备工具集（Category-first 检索、Evidence 召回、相似度护栏校验）、observe-act 循环（检索结果不达阈值时自主重写查询或切换类别）、由模型判断的终止条件（信息充分则生成回答，不足则触发追问或拒答）。离线 Map-Reduce 知识构建侧不是 Agent，而是固定流程的批处理 pipeline，刻意避免使用 Agent——知识资产的稳定性来自确定性流程，引入 Agent 自主性反而会放大噪声。Harness 在 Agent 侧承担护栏、可观测、追溯校验的工程职责。

做法： 将向量入库前的处理定义为知识构建层，而非将原始页面直接切片入库。Map阶段按受控taxonomy形成主题候选；Merge阶段执行别名归一、来源页合并和非标准类别剔除；Reduce阶段生成category_summary和overview，并为每个资产保留来源页和来源文件。在线侧以Category-first检索、单一可信源（SSOT）策略和相似度护栏调用这些类别级知识资产。

技术亮点： 设计Overview、Category Summary、Evidence三层知识资产结构，对齐“概览→主题→证据”的认知路径。类别级聚合降低切片级语义碎片、主题混杂与冗余上下文；结构校验、追溯校验和相似度护栏共同形成质量门禁，使回答可以回溯到具体材料位置。

业务价值： - 售前咨询从检索零散材料转变为调用结构化知识资产，对外输出口径趋于一致 - 项目经验沉淀为可复用知识资产，为后续运营类Agent扩展提供统一知识底座

技术成果： - 交付解决方案知识引擎 solution_advisor - 沉淀Map-Reduce知识构建范式、三层知识资产模型和证据追溯机制

方法论参考： 该设计属于结构化/分层RAG索引构建，而非主张原创通用算法。RAPTOR参考递归聚类与摘要形成多抽象层级的检索节点；Microsoft GraphRAG参考私有语料的结构化索引和预生成群组摘要；HIRO参考语义组织的层级索引与证据簇检索；Contextual Retrieval参考在embedding前补足检索单元的材料级语境。

落地场景二：智能候选人评估系统（招聘业务Agent）

要解决的问题： 简历来源多样、格式不统一，从收到简历到输出技能报告需经过多个处理阶段。常规做法将流程逻辑直接写入业务代码——实现简单，但代价是流程中断后难以从断点恢复、调整阶段顺序需修改代码，人机协同等待被当作异常分支处理而非流水线的正常步骤。

项目定位与 Agent 边界（一）： 项目的核心定位是 Pipeline Harness 工程，而不是单体 Agent。每个阶段以 TaskManifest 为唯一输入，可走两条互斥的执行路径：（1）内部 LLM 直调路径——jd-resolve、analyze、post-interview、skill-report 等阶段在 Python 进程内通过 langchain 调用 LLM 做结构化生成，单次 prompt 拿结构化输出，本质是 LLM 应用，不是 Agent loop；（2）外部 Agent 路径——通过 Executor Adapter 把同一个 task-runner 包进 Codex、Claude Code、OpenCode 三种 AI CLI 中执行，由这些具备完整 tools / observe-act 循环 / 模型自主终止三要素的外部 Agent 来完成同一份工作。

项目定位与 Agent 边界（二）： Harness 真正的工程价值在于让同一份 TaskManifest 在两种执行模式下共用同一套状态边界、审计追溯和回归约束——「LLM 应用」和「外部 Agent」不是在协议层被区别对待，而是在执行层可替换。区分「Agent 做什么」与「Harness 在什么约束下让 Agent / LLM 应用做」是这套设计的核心。

核心设计：

系统基于一套与业务无关的流水线协议（Pipeline Harness），管理三项核心状态：任务当前阶段、执行者身份和产物位置。六个阶段（convert→jd-resolve→analyze→await-interview-feedback→post-interview→skill-report）按固定顺序推进，可跳过但不可乱序。将流水线抽象为独立基础设施，前期设计投入高于直接硬编码——代价是协议层的额外设计工作，收益是调度逻辑与业务场景彻底解耦，后续复用到其他数据处理场景无需修改核心引擎。

其中两个阶段为人机协同等待点，采用事件驱动而非轮询：等待状态持久化到数据库，不占用Worker、无超时；人工确认后以事件唤醒继续。轮询实现简单但持续占用资源且状态不可靠；事件驱动将”等待人工决策”实现为执行引擎的原生语义，而非异常分支中的条件判断。

流水线之外的第二层设计是Agent之间通过结构化合约通信，而非prompt字符串。18个verb和35个结构化错误码构成标准JSON信封——Agent之间、前后端之间（Pi 控制面↔Python后端，Pi 为前端 TypeScript 控制面与产品级管理界面）全部使用同一套合约协议。自然语言灵活但存在固有不确定性——歧义与格式漂移无法在调用侧被程序校验；结构化合约使每一条通信都可被机器验证，故障定位不再依赖人工解读自然语言日志。自然语言仅用于对用户的输出，不做为模块间通信载体。

外部Worker只消费单个TaskManifest，不扫描目录、不自选候选人、不自选JD——安全边界由架构物理约束，不依赖prompt中的行为指令。所有历史写入口退役后只保留一个agent-api bridge作为唯一写路径，配合 Pi 管理界面，流水线状态、等待点、回归触发全部可视化。

第三层设计是对AI产出建立与代码同等级别的回归测试机制。监督模型（Facts-first Supervisor + GuidanceBlock）选择无状态设计——每次从数据库原始任务行和JSON文件重新聚合事实，再从事实推理下一步。缓存状态可以减少重复计算，但会导致AI推理结果依赖不可见的内部状态、事后无法复现；无状态重建虽增加计算开销，但事实不变则推理可重复，完整支持审计追溯。

回归框架在隔离环境中用真实案例回放全链路，12种结构化失败码按优先级定位具体断言——单一pass/fail无法指导修复方向，结构化失败码将"什么错了"与"为什么错"分离，每次回归直接指向具体断言。

交付成果：

• 以 0.1.0 版本发布（2026-06），配套 CHANGELOG / CI / CONTRIBUTING——按正式软件工程标准维护，而非架构原型
• 一个候选人可并行匹配多个JD（Candidate/Evaluation双层域），评估产物独立追踪；Executor Adapter支持分发到 Codex、Claude Code、OpenCode 三种 AI CLI 执行环境
• Harness协议层、合约通信和回归框架的通用性被验证——流水线调度能力可复用到运营、客服、合规审查等其他数据处理场景

2023.06 – 2025.09 Zoetis

项目名称：NGSE（Next Generation Sales Engine）湖仓与AI数据引擎

数据架构师

项目描述： 负责推动Zoetis全球”新一代销售引擎”（NGSE）在中国市场的本地化数据基础架构建设。由于数据跨境传输监管限制，全球统一的销售引擎无法直接在中国部署，本地销售团队无法使用统一的销售流程和推荐策略。项目通过建设符合本地法规的湖仓与AI数据引擎，在守住合规边界的前提下承接全球销售方法论，形成可持续演进的数据服务底座。

解决的问题： - 全球统一的数据与推荐体系无法直接在中国部署，跨境传输限制要求对核心数据集、指标口径和模型链路进行重新设计 - 全球与本地在业务定义、主数据和评价方式上存在口径差异，导致对账困难、特征复用受阻、业务协同成本高 - 销售引擎需要持续稳定地供给数据和评价依据，但原有链路很难同时兼顾合规、安全、可用性和迭代效率

做法： - 区分通用数据需求和中国市场特有需求，在此基础上设计本地湖仓的分层架构和指标口径体系 - 数据链路从原始业务数据一路通到模型输入输出层（原始层→特征层→标签层→模型层），既要跑得动批量、也要撑得住近实时 - 合规方案的核心是数据分类而非禁止跨境：可脱敏聚合的数据走跨境同步，必须依赖本地上下文的数据在境内重建。分层治理让两条路径在同一架构中并行 - 全球与本地口径差异通过指标与特征映射体系管理——配置字段字典和版本管理，确保翻译关受控 - 为算法和策略团队搭建数据服务接口，同时优化核心链路的计算和存储，确保销售周期内关键指标稳定产出

技术亮点： - 湖仓分层在本地合规约束下重新设计——每层（原始沉淀/特征加工/模型服务/业务消费）不照搬全球模板，而是基于本地数据特征和合规要求独立定义 - 指标口径映射与特征映射双轨并行——全球与本地对同一指标的语义差异通过映射表精确定义，避免语义偏差在跨区域协同中被放大 - 数据重建与跨境同步在同一架构内并行——境内依赖型数据在本地重建，可脱敏聚合的数据合规出境，两条路径不互斥 - 数据链路兼容批处理和近实时两种计算模式——销售周期内按场景选择数据时效，同步链路和异步批处理互补运行

业务价值： - 中国区NGSE湖仓与AI数据底座上线运行，全球销售方法论以结构化方式承接落地 - 关键销售与推荐数据具备持续稳定的服务能力，为模型训练和线上推荐提供可靠输入 - 全球与本地关键商业指标的口径对齐和特征映射生效，跨区域效果评估不再各说各话 - 业务团队能按区域和产品线持续跟踪销售引擎带来的业务变化，为后续数字化投入提供依据

技术成果： - 沉淀本地湖仓分层架构、指标与特征映射体系、合规跨境同步方案和数据服务接口规范 - 建立支撑推荐算法、销售策略和业务评估协同演进的数据治理底座

2025.10 – 至今 个人独立开发者

项目名称：塔罗牌智能应用（TarotAI）

全栈开发工程师 / 独立开发者

项目描述： 独立设计并实现面向匿名用户的AI塔罗解读产品，围绕”选类型→写问题→抽牌→看解读”的轻量流程，构建移动端交互、双阶段AI解读链路、离线内容生成工具和后台运营能力，形成支持持续迭代的全栈产品架构。

设计目标： - 把塔罗解读从一次性模型调用变成可配置、可维护、可持续优化的AI内容系统 - 在匿名使用场景下兼顾神秘感、沉浸体验、解读一致性和响应稳定性 - 通过产品化设计把内容生成、体验交互和后台运营能力纳入同一套演进闭环 - 从需求定义、技术选型、架构设计到部署交付全程独立决策与执行，实践了”为端到端结果负责”的完整产品Owner闭环

项目定位（边界澄清）： 本项目不是 Agent 项目——LLM 调用是固定的双阶段生成链路，没有工具调用循环，也不存在模型自主终止判断，属于结构化 LLM 应用而非 Agent。这里列出是为了完整呈现独立交付端到端 AI 产品的能力，不是为了把 LLM 应用包装成 Agent。

核心设计： - 搭建Expo React Native客户端、FastAPI后端和Next.js管理后台，形成移动端、解读服务端和运营后台的分层架构 - 设计四步占卜流程，覆盖离线占卜和AI占卜两种模式，通过卡牌翻转、牌阵布局、步骤推进等动画强化沉浸式体验 - 离线解读设计为预生成内容系统，枚举高频牌面组合、解读维度和问题场景，批量生成结构化解读内容，作为稳定的内容底座 - 在线解读设计为双阶段动态生成链路——先基于用户输入分析可解释的解读维度，再结合牌面组合和用户选择生成个性化解读、启发式引导和行动建议 - 构建独立的AI生成工具链，统一管理提示模板、语言分发、结构化输出和结果回写，让移动端和后台共享同一套内容来源

技术亮点： - 提示词工程作为核心控制机制，统一约束角色设定、解读维度、输出风格和内容边界，保证AI每次解读的口径一致、可持续维护 - 离线预生成和在线即时生成双轨协同，兼顾内容稳定性、响应效率和开放式提问场景的适配能力 - 匿名身份、历史记录、管理后台和配置化运营能力共同支撑产品持续演进，不是停留在单次解读工具层面 - 客户端、服务端、生成工具和后台之间靠模块化接口和结构化输出对接，加新牌阵、解读模式只需扩展不改核心

业务价值： - AI解读产品在匿名场景下具备持续演进能力 - 把解读能力从即时生成变成可复用的内容系统，产品更稳定，后续迭代也更顺畅 - 移动端体验、内容生产和后台运营之间的一致性得到保障，支撑持续调优和产品化运营 - 预生成保障基础质量，动态生成覆盖开放式提问——两条路径在同一产品架构中独立运行、互不阻塞

技术成果： - 交付TarotAI移动端、后台运营能力、FastAPI解读服务和AI内容生成工具链 - 沉淀双阶段AI解读流程、预生成内容体系、沉浸式交互方案和配置化运营能力

教育背景

职业经历摘要