如何设计一个AI Agent系统

前言

什么是AI Agent

AI Agent新技术不断涌现，是属于技术人的幸福时刻。

来自2025年6月Andrej Karpathy在YC的主题演讲《Software in the era of AI》，附演讲视频地址（https://www.youtube.com/watch?v=LCEmiRjPEtQ）

Andrej Karpathy：师从李飞飞、Tesla AI 总监（FSD）、OpenAI 研究科学家、Vibe Coding的提出者

图片来自The Rise and Potential of Large Language Model Based Agents: A Survey

LLM 是新的操作系统内核 (LLM OS)，而 Agent 就是在这个新 OS 上运行的程序。--Andrej Karpathy

Agent基础知识

• Planning（从“直觉”到“逻辑”）：是指 Agent 将一个宏观的、抽象的目标拆解为一系列可执行的子任务，并根据环境反馈动态调整策略的过程。
• Memory（突破上下文限制）：Memory 是 Agent 存储、检索和管理信息的机制，它决定了 Agent 能在多大程度上利用过去的交互历史和外部知识。
• Tools（连接数字世界的接口）：Tools 是 Agent 的“扩展能力”。LLM 仅受限于预训练数据，而 Tools 让它可以联网、计算、绘图甚至控制物理设备。
• Action（从决策到执行）：Action 是规划和工具使用的最终落脚点，是 Agent 对环境产生的实际影响。

你现在是电商平台内容安全团队的资深审核专家，精通最新的广告法和平台营销规范。你的任务是审查商家提交的双11大促商品短标题和营销文案。审查重点：绝对化用语（如“第一”、“顶级”）、虚假比价（如“原价999，现价9.9”无依据）、诱导欺诈（如“点击领红包”实则引流）。请以严谨、专业的口吻给出审计报告，指出违规内容、风险等级 (高/中/低) 和具体的合规修改建议。

你是一个资深的电商文案专家。你的任务是根据提供的商品关键属性，生成简洁、吸引人且符合SEO规范的商品标题。标题应包含品牌、核心卖点、适用人群/场景等关键信息，长度控制在 30-60 个字符之间。Few-Shot Examples:Input: {"brand": "Apple", "model": "iPhone 15 Pro", "color": "原色钛金属", "storage": "256GB", "features": ["A17 Pro芯片", "4800万像素主摄", "USB-C接口"]}Output: "Apple iPhone 15 Pro (256GB) 原色钛金属 移动联通电信5G手机 A17 Pro芯片"Input: {"brand": "Nike", "category": "跑步鞋", "series": "Air Zoom Pegasus 40", "gender": "男", "color": "黑/白", "features": ["透气", "缓震", "回弹"]}Output: "Nike耐克官方Air Zoom Pegasus 40男子跑步鞋透气缓震回弹运动鞋"

你是一个智能商品信息结构化助手。任务是从非结构化的商品详情描述中，提取出关键属性值，并严格按照指定的 JSON Schema 输出。不要包含任何 JSON 以外的内容。
[Schema Definition]{  "type": "object",  "properties": {    "brand": {"type": "string", "description": "品牌名称"},    "model": {"type": "string", "description": "具体型号"},    "material": {"type": "string", "description": "核心材质成分"},    "suitable_for": {"type": "array", "items": {"type": "string"}, "description": "适用人群/场景列表"}  },  "required": ["brand"]}User Input: "全新阿迪达斯三叶草系列休闲鞋，牛皮帮面，经典贝壳头设计，情侣款，出街必备。"Model Output: {"brand": "阿迪达斯", "model": "三叶草系列休闲鞋", "material": "牛皮", "suitable_for": ["情侣", "出街"]}

# Available ToolsYou have access to the following tools:## `query_sku_inventory(sku_id: str, warehouse_code: str = "MAIN_WH") -> int`- **Description**: Use this tool to check the current available inventory quantity of a specific SKU in a given warehouse.- **Parameters**:    - `sku_id`: The unique identifier of the Stock Keeping Unit (e.g., "SKU_887799").    - `warehouse_code`: The code of the warehouse to query. Defaults to "MAIN_WH" (Main Warehouse). Use "BONDED_WH" for cross-border items.- **Usage Example**: To check inventory for SKU 'SKU_123' in the bonded warehouse, call `query_sku_inventory(sku_id="SKU_123", warehouse_code="BONDED_WH")`.

Task: "为一款即将参加双11大促的‘智能降噪耳机’撰写一条吸引人的商品短标题，要求突出降噪效果和优惠信息。"Self-Consistency Strategy: Prompt 模型生成 5 条不同的短标题草案，例如："双11直降！智能降噪耳机，静享好声音""强力降噪，沉浸体验，双11特惠来袭""静无止境，智能降噪耳机双11半价抢""双11必买：智能降噪耳机，瞬间远离喧嚣""超强降噪黑科技，双11限时优惠，错过等一年" 然后通过人工或自动化评估机制，选择最符合要求、出现频率或得分最高的一条作为基础。假设选择了第3条。Self-Refine Strategy (for generated copywriting):Initial Output: "静无止境，智能降噪耳机双11半价抢"Refine Prompt: "这条标题虽然突出了降噪和优惠，但略显平淡，不够吸引眼球。请针对追求高品质生活和性价比的年轻人群体，优化这条标题，使其更具紧迫感和诱惑力，可以适当使用一些网络热词或强调符号。"Refined Output: "🔥双11炸场价！智能降噪耳机【半价】秒杀，一秒入静，手慢无！🚀"

Task: "用户订单含商品A (100元), B (200元), C (50元)。用户有'满300减30'平台券（全场通用）、'B商品立减20'单品券、500京豆（抵5元，通用）。请计算最终应付金额。"CoT Output:Let's calculate the order price step by step.1.  **Calculate Initial Total**: 商品总价 = 100 (A) + 200 (B) + 50 (C) = 350 元。2.  **Apply Item-Level Discount**: 应用'B商品立减20'单品券。商品B价格变为 200 - 20 = 180 元。新的商品总价 = 100 (A) + 180 (B) + 50 (C) = 330 元。3.  **Apply Platform/Cross-Store Discount**: 判断是否满足'满300减30'平台券条件。当前总价 330 >= 300，满足。应用平台券后总价 = 330 - 30 = 300 元。4.  **Apply Virtual Currency**: 应用 500 京豆抵扣 5 元。最终应付金额 = 300 - 5 = 295 元。

Task: "双11期间，针对华东地区的爆品订单，设计一个兼顾时效和成本的仓配履约方案。"ToT Process:Thought 1 (分支一: 极致时效):Proposal: 全部从上海中心仓发货，使用顺丰特快。Evaluation: 时效最优，但成本极高，且中心仓压力巨大，可能爆仓。评分: 6/10。Thought 2 (分支二: 成本优先):Proposal: 启用华东地区所有前置仓和门店店仓进行就近发货，使用通达系快递。Evaluation: 成本最低，但前置仓库存深度不足，缺货率高，且物流服务商时效不稳定，客诉风险大。评分: 7/10。Thought 3 (分支三: 分层履约):Proposal: 根据用户画像分层。高价值用户/付费会员从中心仓发顺丰；普通用户订单利用算法拆单，有货的前置仓就近发普通快递，缺货部分中心仓补发。Evaluation: 平衡了体验和成本，复杂度可控，是行业主流方案。评分: 9/10。Decision: 选择 分支三 进行详细方案设计。

Task: "为一款新发布的中高端扫地机器人制定冷启动营销策略。"GoT Process:Node A (市场分析): 分析竞品价格带和功能差异。 -> Node B (目标用户画像): 定义核心受众为“一线城市养宠家庭”。Node C (渠道策略): 提出多渠道方案：站内搜索广告 + 小红书种草 + 直播带货。Node D (内容策略): 提出主打“吸毛发不缠绕”和“静音”的卖点。Aggregation Node E (策略融合): 将 A, B, C, D 的信息融合，制定一个整合营销计划。Refinement Node F (迭代优化): 基于 Node E，评估预算分配合理性，提出先在小红书做两周种子用户测评口碑，再配合站内大推的优化路径。 -> 回流到 Node E 进行调整。

User Question: "为什么我的快递三天了还没动？"Initial Agent Output: "亲，大促期间物流比较慢，请您耐心等待。"Reflection Trigger (System): "请检查你的回答是否具备同理心，是否提供了具体的订单状态信息，是否给出了明确的解决方案或预期。"Agent Reflection Output:Review:我的回答过于敷衍，缺乏同理心。没有查询用户的具体订单状态，也没有给出具体的预计到达时间或解决方案，用户体验不好。Revised Answer:"亲，非常抱歉给您带来不好的体验。我刚帮您查询了订单（单号：SF123456），目前包裹已到达【杭州转运中心】，正准备发往您的城市。受双11大促影响，物流比平时晚了约1天。根据当前进度，预计明天（11月12日）能送到您手中。我会持续为您关注物流动态，请您再耐心等待一下。"

Tool Definition (Schema):{  "name": "apply_for_return",  "description": "为用户的指定订单申请退货服务。需校验订单状态是否支持退货。",  "parameters": {    "type": "object",    "properties": {      "order_id": {"type": "string", "description": "电商平台订单号"},      "return_reason": {"type": "string", "enum": ["quality_issue", "wrong_item", "no_longer_needed"], "description": "退货原因代码"},      "pickup_method": {"type": "string", "enum": ["door_to_door", "express_station"], "description": "取件方式"}    },    "required": ["order_id", "return_reason"]  }}#交互流程:User: "我买的鞋子码数不对，订单号是 889900，我想退货，让快递员上门取件吧。"Agent (Think): 用户意图是退货，提供了订单号和取件方式。退货原因可归类为 'no_longer_needed' (不喜欢/不合适)。调用 apply_for_return 工具。Agent (Tool Call Output): {"name": "apply_for_return", "arguments": "{\"order_id\": \"889900\", \"return_reason\": \"no_longer_needed\", \"pickup_method\": \"door_to_door\"}"}Host Program: 调用售后中心 API，成功提交申请。Agent (Final Response): "好的，已为您申请了订单 889900 的上门退货服务。快递员预计在明天上午联系您取件，请保持电话畅通。"

场景: 一个电商平台的商品信息分散在多个异构系统中：基础信息在 MySQL 数据库，图片和视频在 OSS 对象存储，库存和价格在 Redis 缓存，用户评价在 Elasticsearch。应用: 通过 MCP，这些异构的数据源被封装为统一的资源接口。Agent 无需了解底层的 SQL、Redis 命令或 ES 查询语法，只需通过标准的 MCP 指令，如 read_resource("product://base/sku_123")、read_resource("product://media/sku_123")、read_resource("product://inventory/sku_123")，即可获取和聚合一个商品的完整信息，大大简化了跨系统数据操作的复杂度。

/ecommerce_loss_prevention/├── SKILL.md                # 技能说明书：用途、限制、输入输出规范├── tools/│   ├── check_activity_conflict.py   # 检查营销活动互斥规则│   └── validate_pricing_rule.py     # 验证价格配置是否合规├── knowledge/│   └── loss_prevention_rules_v2.json  # 最新资损防控规则库└── prompt_template.yaml     # 领域专属 Prompt 模板（含角色设定、输出格式、安全兜底）

User Task: "帮我分析一下店铺上个月的销售数据（已上传 sales_data.csv），找出销售额最高的 Top 5 商品，并画一个饼图看看各品类的销售占比。"Agent Action:编写 Python 代码，使用 pandas 读取 CSV。按商品 ID 分组汇总销售额，排序取 Top 5。按品类分组汇总销售额，使用 matplotlib 绘制饼图并保存。Agent Final Response: "上个月销售额 Top 5 的商品分别是 [商品A, 商品B, ...]。各品类销售占比饼图已生成（附图），可以看出‘数码家电’类目贡献了 60% 的销售额。"

背景：商家经常咨询复杂的平台发货时效和处罚规则。RAG Process:Indexing: 将《电商平台商家发货管理规范.pdf》切片并 Embedding 存入向量库。User Query: "我是经营生鲜类目的，春节期间的发货时效要求是什么？晚发了会怎么罚？"Retrieval: 系统检索到规范中关于“特殊品类（生鲜）发货要求”和“春节特殊时段履约规则”以及“延迟发货违规处理”的相关段落。Generation: Agent 基于检索到的规则原文，准确回答商家春节生鲜发货的时效要求及对应的处罚措施。

策略: 采用 实体记忆 (Entity Memory) 策略。
Process: 在对话过程中，持续从用户的语句中提取关键购物意图实体（如 "需求: 跑步鞋", "品牌: 耐克", "预算: 500左右", "偏好: 减震好"），存储在结构化的状态中。在每一轮推荐时，都基于当前积累的所有实体状态调用搜索服务，确保推荐结果精准且连贯。

场景: 去年双11，Agent 协助配置一个复杂的“预售+尾款”活动时，因未考虑到预售定金膨胀与店铺券叠加的互斥规则，导致活动上线后出现计价 Bug。Memory Store: 事后存储一条经验：{"task_type": "activity_config", "scenario": "presale_and_coupon", "reflection": "配置预售活动时，必须先检查与现有店铺券的叠加互斥规则，需调用规则中心 check_conflict 接口确认。"}New Task: 今年618配置类似活动时。Action: Agent 检索到这条经验，主动先调用接口检查互斥规则，避免了同样的问题。

Task: "帮我买一个全网最便宜的国行 Switch OLED 主机，要求全新正品。"Loop 1: Thought: 需在主要电商平台搜索商品价格。Action: 调用京东、天猫、拼多多搜索 API。 Observation: 获得各平台价格列表和商家信息。Loop 2: Thought: 初步筛选出价格最低的几个链接。需要进一步核实是否为“国行”、“全新”、“正品”（通过查看商家资质、用户评价、问答）。 Action: 调用商品详情和评价查询 API。 Observation: 发现最低价的拼多多链接是港版，次低价的淘宝店评价中有提到是二手充新。京东自营价格稍高但确定是国行正品。Loop 3: Thought: 综合考虑价格和信任度，京东自营是符合要求的最低价。 Final Answer: "推荐购买京东自营的链接，价格为 NT$xxxx，虽然不是全网绝对最低，但能确保是国行全新正品，售后有保障。"

Task: "协助一家新企业商家完成平台入驻流程。"Phase 1: Planning:Planner Output: 1. 收集企业资质文件（营业执照、法人身份证）。 2. 调用工商 API 核验资质真实性。 3. 引导商家填写店铺基础信息和类目资质。 4. 提交平台人工审核。 5. 审核通过后，协助商家缴纳保证金并激活店铺。Phase 2: Execution:Executor Agent: 顺序执行计划。第一步通过对话收集文件，第二步调用 API 核验，依此类推。

Task: "为一款高端母婴产品圈选一波目标用户进行营销触达。"Execution: Agent 初次圈选了“过去30天浏览过母婴频道的一二线城市女性”。营销效果（点击率）不佳。Reflexion: Agent 反思认为，浏览行为太宽泛，未排除已购买用户，且未考虑购买力。应该增加“高消费力标签”和“近3个月未购买同类目商品”的过滤条件。Retry: 基于反思更新圈选条件，重新执行任务，提升营销ROI。

故障协调 Agent (Incident Coordinator Agent)：负责接收故障报警，创建故障工单，初步判断故障影响范围，协调各专业 Agent 进行排查，汇总排查结果，并向相关人员通报进度。应用服务故障定位 Agent (Application Service Troubleshooting Agent)：专注于应用层面的故障排查。它可以分析应用日志、Trace 调用链、服务运行指标（如 QPS、RT、Error Rate），识别出服务异常、代码 Bug、配置错误等问题。RPC 接口故障定位 Agent (RPC Interface Troubleshooting Agent)：专门负责 RPC 接口层面的故障诊断。它可以分析 RPC 调用成功率、延迟、超时、限流熔断等指标，定位出接口性能瓶颈、依赖服务故障、网络抖动等问题。数据库故障定位 Agent (Database Troubleshooting Agent)：深入数据库层面进行故障排查。它可以分析数据库连接池、慢查询、锁等待、事务、主从延迟、硬件资源（CPU、内存、磁盘 I/O）等指标，识别出数据库性能瓶颈、死锁、索引缺失、硬件故障等问题。离线资源故障定位 Agent (Offline Resource Troubleshooting Agent)：负责离线大数据处理任务的故障排查。它可以分析离线任务执行日志、资源调度情况、数据产出质量等，定位出任务失败、数据延迟、资源抢占等问题。中间件故障定位 Agent (Middleware Troubleshooting Agent)：负责消息队列、缓存、搜索引擎等中间件的故障排查。它可以分析中间件的集群状态、消息积压、缓存命中率、查询延迟等指标，定位出中间件性能瓶颈、集群故障、配置错误等问题。协作流程：当监控系统发出“订单创建失败率飙升”的报警时，故障协调 Agent 立即响应，创建故障工单，并通知相关 Agent 进行排查。应用服务故障定位 Agent 分析Trace调用链，发现订单创建接口调用库存服务的 RPC 接口大量超时。RPC 接口故障定位 Agent 进一步分析，确认库存服务的 RPC 接口延迟极高。数据库故障定位 Agent 深入分析库存数据库，发现存在大量的行锁等待和慢查询，导致数据库 CPU 使用率飙升。最终，各 Agent 将排查结果汇总给 故障协调 Agent，得出结论：是由于某个热点商品的库存更新操作引发了数据库行锁竞争，导致库存服务响应超时，进而引发订单创建失败。

Environment: 电商推荐系统仿真环境（基于历史用户行为数据构建）。State: 用户当前特征、上下文信息、候选商品池。Action: 选择一种推荐策略（如“侧重点击率”、“侧重转化率”、“侧重多样性”）或调整排序公式的参数。Reward: 根据模拟用户在 Agent 决策下的反馈计算奖励（如用户点击得 +1 分，下单得 +10 分，负反馈得 -5 分）。Learning: Agent 通过大量模拟交互，利用强化学习算法（如 PPO）不断调整策略，以最大化长期累积奖励（如 GMV 或用户 LTV）。

Agent工程实践

• 核心关注点的转变：从“功能实现”到“目标达成”
  传统研发关注如何精确实现预设的每一个功能点；而Agent研发的核心是定义一个高级目标，并赋予其自主规划、调用工具以达成任务的能力。
• 流程驱动力的转变：从“计划驱动”到“实验驱动”
  Agent研发并非线性的“需求-开发-测试-发布”瀑布流，而是一个紧密的 “评估-迭代”循环。不再追求输入与输出之间绝对的、确定的映射关系，转而追求在复杂环境中行为的可靠性与鲁棒性。
• 协作方式的转变：从“基于接口”到“基于目标与评估”
  团队围绕一个共同的、可执行的评估集进行协作。这个评估集由业务专家、Agent架构师和提示词工程师共同定义和维护，它包含了多样化的场景和明确的评分标准，是团队统一的目标导向。

AI Agent 研发目前还没有形成像软件设计模式（如单例、工厂、观察者等）那样标准化、广泛共识的“设计模式”体系。

本节中示意图来自  Anthropic-Building effective agents

• 范式一：最小可用范式

• 单轮触发：每次用户请求触发一次处理流程，整体是单轮或极少轮。
• 线性流程：在一次流程中，最多经历：意图识别 → RAG 检索 → 工具调用 → LLM 汇总输出，没有显式的多步规划或循环控制。
• 无状态设计：Agent 不维护长期任务状态（仅依赖 LLM 上下文窗口的短期记忆），也不做复杂任务拆解和多阶段决策。

• 高效率与低延迟：由于推理步骤最少（通常只调用 LLM 一次），响应快，适合对时间敏感的场景。
• 成本效益高：LLM 调用次数少，且无需复杂的规划提示，运行成本最低。
• 实现和维护简单：代码库简单，易于调试，适合作为复杂 Agent 的核心组件或原型。
• 可解释性较高：执行路径清晰，错误追踪直接。

• 缺乏多步规划能力：无法处理需要连续决策、迭代优化或解决复杂依赖关系的深度任务。
• 工具使用局限性：对工具的复杂组合或条件触发能力不足，往往只能按顺序调用单个工具。
• 上下文依赖性强：短期记忆仅依赖 LLM 的上下文窗口，容易遗忘旧信息或被长对话淹没。

• 范式二：工作流式（workflow）

类别	示意图
链式
路由
并行

• 预定义执行路径：任务的流转逻辑（顺序、分支、循环、并行）在开发阶段即已确定，而非由 LLM 在运行时“即兴发挥”。
• 结构化任务拆解：通过固定流程、意图分流、并发处理或状态流转，将复杂问题结构化为具体的步骤。
• 关注控制流：系统的核心价值在于如何编排 LLM 的输入输出流向，确保逻辑的严密性和合规性。
• 确定性优先：虽然节点内部利用 LLM 进行智能处理（如填空、判断），但节点间的流转是确定的，强调规则和逻辑的约束。

• 高可预测性与可靠性：每一步的输入输出明确，行为边界清晰，极大地降低了 LLM 的幻觉风险；非常适合测试验证、合规审计以及对错误零容忍的场景。
• 强大的监控与调试能力：支持对每个节点设置 SLA（服务等级协议）、超时中断和失败重试机制；完整的执行日志支持问题回放和用户投诉的深度分析。
• 性能与资源效率：对于 I/O 密集型任务（如多源搜索），并行工作流可大幅降低总耗时；无无限动态分支，资源消耗稳定，便于容量规划；子流程可模块化（插件化），不同业务线可复用同一套意图识别或处理逻辑。
• 协作友好：业务人员可以通过流程图参与设计，开发人员负责实现，分工明确；支持灰度发布和 A/B 测试（针对路由策略），降低上线风险。

• 灵活性受限，难以应对未知：缺乏探索性，无法处理开放式问题；交互僵化，用户体验较为机械，类似“填表”而非自然对话。一旦用户中途改变意图或跳出流程，系统往往无法自适应。
• 复杂度与维护成本：设计门槛高，要求开发者对业务过程有极深的理解，初始建模（尤其是状态机）难度大；随着业务场景增加，工作流图可能发生爆炸（状态爆炸、路由规则复杂），导致“维护地狱”；新增或修改流程往往涉及工程代码变更，迭代速度受限于流程设计。
• 集成与聚合难题：意图识别瓶颈，如果路由节点的分类模型出错，则整个后续流程都会错配；上下文隔离，跨子流程的信息传递往往比较困难；结果聚合问题，并行任务的输出结果在结构统一、排序和权重分配上处理难度较大。

• 范式三：动态规划类

• 运行时动态决策：执行路径不是开发者预设的，而是由 Agent 根据当前环境状态和任务目标实时生成。
• 推理驱动行动：迭代式推理，通过 思考--> 行动-->反馈的闭环，逐步逼近答案；全局规划，通过生成完整的计划指导后续的(执行，并在必要时进行重新规划。
• 高度自治：Agent 具备自我修正能力，能够处理执行过程中的报错或意外信息，并在不修改代码的情况下探索新路径。
• 工具使用灵活性：只要工具在行动空间内，Agent 可以根据需要以任意顺序、任意次数调用，无需硬编码调用逻辑。

• 极高的灵活性与适应性：无需预定义死板流程，能适应未知环境和千变万化的用户需求；支持信息逐步揭示，能处理“一开始不知道怎么做，试一下才知道”的探索性任务。
• 具备解释性与可控性（相对黑盒模型）：过程透明，ReAct 的思考日志和 Plan-and-Execute 的计划列表，让用户能清晰看到 Agent 的思考路径和规划逻辑；人机协同友好，中间产生的“计划”可供人类审核、修改或重排，便于介入干预。
• 自然发现新路径：只要提供了足够的基础工具，Agent 可能会组合出开发者未曾预想到的解决方案路径。

• 稳定性与可靠性挑战：循环与死锁，Agent 可能陷入无效的思考循环（如反复调用同一工具报错），或在规划时遗漏关键步骤；结果不可控：相同的输入在不同时间可能走出完全不同的路径，输出结果的方差大，难以满足强确定性业务的需求。
• 对模型能力的强依赖：推理瓶颈，极度依赖 LLM 的逻辑推理能力。如果 LLM 在规划或决策阶段“想偏了”，后续执行将全部错误；上下文限制，在长任务中，Observation（环境反馈）可能非常长，容易导致关键信息被截断或遗忘。
• 工程化难点：延迟高，ReAct 模式每一步都需要一次 LLM 推理，多步任务导致响应极慢；成本不可预测：无法预知 Agent 会调用多少次工具、消耗多少 Token，难以进行精确的费用预算；安全风险：由于 Agent 具有高度自主权，若无严格沙箱，可能生成恶意的工具调用指令。

案例分享：AI需求资损分析

• 资源与风险的错位分配

• 专家经验的规模化难题

• 评估流程效率瓶颈

• 运行态（面向当次需求）：基于业务架构和生产关系统一设计业务领域Agent， MoE架构由总控协调器统一调度各领域专家Agent，基于多租户架构快速支持各业务产品线独立接入、调试、灰度与上线，统一技术链路与能力组件，支持与产品线共建。
• 归档与保鲜（面向长期演进）：需求归档和知识保鲜是本产品可持续的关键，前者将每次需求的分析结论、命中风险点、校验脚本与效果指标结构化沉淀；后者以自动更新的方式维护业务/技术/风险知识，降低对人工专家持续维护的依赖，避免知识库过期导致模型输出漂移，从而让系统具备“越用越准、越用越省人”的复利效应。
• 研发态（面向稳定迭代）：通过构建领域需求数据集与分析效果验证Agent，对模型输出进行打标与召回率度量，同时借助需求归档与知识保鲜Agent将真实场景中的新增风险点动态回流至底层知识库，实现了分析能力的迭代升级。

• Step1：判断是否涉及资损。先通览PRD和技术文档，如果本次需求改动是围绕新增或者修改商业活动玩法，涉及资金链路改动的就是资损需求。
• Step2：需求改动点和技术实现点提炼。 如果需求涉及资损，则重点关注PRD中涉及的业务玩法规则以及技术文档中涉及资金链路改造的部分，忽略掉非资损相关的部分。
• Step3：丰富业务需求提炼内容。如果文档里提到了一些特殊业务名词或者行业术语，比如平台返、递进满减等，还有一些技术名词，比如应用缩写等，需要了解这些知识点来丰富业务需求提炼内容，这样一个更丰富的资损需求内容呈现在眼前了。
• Step4：召回相似资损场景。本次需求是全新的能力还是之前产品能力的迭代，如果是后者可以重点参考历史需求的资损场景分析结果。在之前沉淀的所有资损场景分析文档里是否有相似业务规则和资金链路的资损场景，以及各个领域持续沉淀的失血模型给资损场景分析提供输入，还有历史出现过的资损故障和事件都可以作为借鉴。总而言之用于召回本次需求相关的资损场景，但这还不是最终的输出结果。
• Step5：资损布控场景分析。有了丰富后的资损需求提炼内容和召回的资损场景就可以进行最终的资损场景分析，确保分析过程跟本次需求高度相关，给出最终的资损场景列表。

• 多源输入标准化：降低信息缺失与偏差
  资金风险经常不是PRD一句话能解释清楚，关键风险往往藏在技术方案和代码变更中，整合研发过程pipeline的产物，避免仅分析代码或仅分析文档导致的遗漏，确保业务预期与技术实现的一致性校验。
• 需求点/实现点抽象：建立可推理的中间表示
  直接从长文生成场景容易漂移，因此需要先把业务预期和技术实现抽成结构化要素，相当于给模型建立可控的推理地基，减少幻觉，再次提升一致性。
• 变更影响面分析：把风险评估从“可能”变成“触达范围”
  资金风险能否发生取决于变更触达了哪段资金链路、哪些状态流转、哪些账务/优惠/结算口径等，从单点变更扩展至全链路影响，避免传统分析仅关注局部代码的局限性。
• 资金风险描述语言：统一表达、便于复用与保鲜
  用统一的风险描述语言把“业务预期—链路特征—校验策略—校验点—核对脚本”串起来，输出结果可直接用于相似资损场景召回和核对脚本开发，将AI分析结论转化为可执行的防控动作。

• Leve1：明确事实查询，直接从数据中提取答案无需推理。
• Level2：隐含事实查询，需要基本逻辑或者常识推理来组合信息。
• Level3：可解释推理查询，不仅需要事实还需要领域内的推理规则。
• Level4：隐藏式推理查询，需要从历史数据中挖掘策略。

• 语义对齐能力（业务上下文）
  解决“术语、玩法、规则等”在不同团队/文档中的表述差异，保证Agent对业务预期的理解稳定一致，避免因口径不一造成误判或漏判。
• 链路落点能力（技术上下文）
  让风险推导能从抽象描述落到具体系统与数据对象：影响到哪些应用/接口/扩展点/表字段/指标口径。资金安全的核对脚本必须可执行，这要求知识体系天然支持“从变更到链路到数据”的可追溯。
• 经验复用能力（风险上下文）
  资金风险高度重复出现（如重复计费、漏计、幂等缺失、补偿不一致、状态机错乱等），风险知识库的作用是把历史事故与最佳实践沉淀为可复用的“风险模式+校验点+脚本模板”，帮助Agent在新需求里快速召回相似风险并完成校验闭环。
  
  

个人实践体会

• 从“最小可用范式”开始，压榨架构潜力，渐进式复杂，遵循“奥卡姆剃刀”。

• 混合架构是落地常态，“工作流外壳 + 智能内核 + 知识管理”，避免Agent失控。

• 智能是奢侈品，稳定是必需品，在智能、可控和成本找到最优平衡点。

• 没有银弹，AI极大地消除了次要困难，但无法解决根本困难，对人要求更高。

• Agent参与者都需要深度理解业务，无论对于架构设计和prompt工程都非常重要。

• 领域知识壁垒比想象中高，包括来自平台沉淀和专家积累等，关注质量和持续性。

• 无评估，不迭代，无数据，不优化，不能用感觉效果不错代替量化验证。

• Agent能力+用户体验（过渡/重做）=好Agent产品，一线同学每天要面对非常多的Agent。

• 拉长时间看，在特定范围内Agent比人更可靠，Agent会成为团队的一份子。

团队介绍