[{"data":1,"prerenderedAt":5917},["ShallowReactive",2],{"agent:developer-digital-employee-workflow-agent-coding-agent-boundaries\u002F":3,"agent-wiki-navigation":1151},{"id":4,"title":5,"body":6,"commentId":1140,"description":15,"draft":1141,"extension":1142,"meta":1143,"navigation":1144,"order":1100,"path":1145,"section":1146,"seo":1147,"stem":1148,"updated":1149,"__hash__":1150},"agent\u002Fagent\u002Fdeveloper-digital-employee-workflow-agent-coding-agent-boundaries.md","研发数字员工如何工作：Workflow、Agent 与 Coding Agent 的职责边界",{"type":7,"value":8,"toc":1094},"minimark",[9,16,22,25,28,34,37,42,45,48,51,54,59,64,67,78,81,85,88,91,116,119,124,127,133,136,140,143,146,149,172,175,179,182,202,205,208,214,218,222,225,245,248,251,257,260,264,267,287,290,310,313,317,320,326,329,332,335,339,342,362,365,369,372,392,395,399,402,454,457,462,466,469,473,476,482,485,488,493,496,500,503,523,526,529,533,536,542,545,551,554,558,561,564,567,571,574,591,594,598,601,605,611,613,619,622,626,632,634,640,643,647,653,656,661,664,668,672,678,681,685,691,694,697,701,707,710,714,720,723,726,730,733,805,808,814,817,823,827,831,834,840,843,847,850,882,886,893,899,902,906,909,915,918,938,941,945,948,954,957,963,966,972,975,979,982,985,1002,1005,1008,1013,1016,1022,1025],[10,11,12],"p",{},[13,14,15],"em",{},"从控制流归属出发，分析企业工作流与 Agent 的关系，明确开发数字员工中确定性流程、模型判断和代码执行的职责边界。",[10,17,18],{},[19,20,21],"strong",{},"系列：从零构建企业级 AI Agent · 第 03 篇",[10,23,24],{},"前两篇文章分别讨论了企业级 Agent 的总体挑战，以及智能开发人员工作台的产品定位和任务模型。",[10,26,27],{},"在第二篇中，我们提出了一个基本架构原则：",[29,30,31],"blockquote",{},[10,32,33],{},"模型提出判断，确定性程序负责验证和执行约束，企业系统保存最终事实，人负责高风险和高歧义节点。",[10,35,36],{},"但这个原则真正落到实现时，还会遇到一个更具体的问题：",[10,38,39],{},[19,40,41],{},"研发数字员工的工作过程，究竟应该预先编排成 Workflow，还是交给 Agent 自主决定？",[10,43,44],{},"一方面，企业流程需要稳定、可追踪和可审计；另一方面，需求分析、问题诊断和代码修改又很难预先穷举路径。如果所有步骤都被固定，系统很容易退化成僵硬的自动化脚本；如果所有控制权都交给 Agent，系统又难以保证权限、状态和结果的可靠性。",[10,46,47],{},"通用 Agent 兴起之后，传统工作流编排产品在市场叙事中的存在感似乎也在下降。用户更愿意说“交给 Agent 完成”，而不是先打开流程画布，逐个配置触发器、条件和节点。",[10,49,50],{},"这是否意味着 Agent 将替代 Workflow？二者是互斥的 A 与 B，还是可以相互组合？开发数字员工又应该如何选择？",[10,52,53],{},"本文尝试从“谁拥有控制流”这个问题出发，回答这些疑问。",[55,56,58],"h2",{"id":57},"一先澄清四个容易混淆的概念","一、先澄清四个容易混淆的概念",[60,61,63],"h3",{"id":62},"_11-业务流程描述组织如何完成一项工作","1.1 业务流程描述组织如何完成一项工作",[10,65,66],{},"业务流程表达的是企业协作方式。例如一个研发任务可能经历：",[68,69,75],"pre",{"className":70,"code":72,"language":73,"meta":74},[71],"language-text","需求分析\n→ 技术方案设计\n→ 开发与自测\n→ Code Review\n→ 提测\n→ 测试\n→ 上线准备\n→ 发布\n","text","",[76,77,72],"code",{"__ignoreMap":74},[10,79,80],{},"业务流程包含的不只是技术步骤，还包括角色分工、质量要求、审批责任和组织规则。它首先是一种业务约定，并不天然等于某个软件产品中的流程图。",[60,82,84],{"id":83},"_12-workflow-把流程转化为可执行状态","1.2 Workflow 把流程转化为可执行状态",[10,86,87],{},"Workflow 负责将业务过程变成系统可以执行、等待和恢复的状态模型。",[10,89,90],{},"很多人把 Workflow 理解成固定的线性步骤。实际上，它可以包含：",[92,93,94,98,101,104,107,110,113],"ul",{},[95,96,97],"li",{},"条件分支和循环。",[95,99,100],{},"并行任务。",[95,102,103],{},"外部事件。",[95,105,106],{},"人工任务和审批。",[95,108,109],{},"超时与重试。",[95,111,112],{},"错误处理和补偿。",[95,114,115],{},"动态子流程。",[10,117,118],{},"Workflow 的“确定性”并不意味着每次都走完全相同的路线，而是：",[29,120,121],{},[10,122,123],{},"哪些状态是合法的、什么事件可以触发变化、进入下一阶段需要什么条件，原则上由程序或流程定义预先约束。",[10,125,126],{},"例如：",[68,128,131],{"className":129,"code":130,"language":73,"meta":74},[71],"代码修复完成\n→ 必要检查是否通过？\n├── 否：返回修复\n└── 是：是否已经部署测试环境？\n         ├── 否：等待部署\n         └── 是：标记已修复，等待测试回归\n",[76,132,130],{"__ignoreMap":74},[10,134,135],{},"不同任务可以走过不同路径，但不能跳过组织要求的状态和证据。",[60,137,139],{"id":138},"_13-agent-在运行时决定下一步","1.3 Agent 在运行时决定下一步",[10,141,142],{},"Agent 的核心不只是调用大模型，而是让模型拥有一部分控制流决定权。",[10,144,145],{},"Anthropic 将 Workflow 与 Agent 区分为：前者通过预定义代码路径编排模型和工具，后者由模型动态决定过程和工具使用。对于路径明确、重复性高的任务，Workflow 更可预测；对于无法提前知道具体步骤的任务，Agent 更有价值。",[10,147,148],{},"例如，面对一个接口偶发 500 的问题，Agent 可以在运行时决定：",[92,150,151,154,157,160,163,166,169],{},[95,152,153],{},"先查询日志还是先阅读代码。",[95,155,156],{},"需要检查哪些模块。",[95,158,159],{},"是否需要查找历史 Bug。",[95,161,162],{},"当前信息是否足够。",[95,164,165],{},"应该调用哪些工具。",[95,167,168],{},"需要补充哪些测试。",[95,170,171],{},"是否应该向开发人员提问。",[10,173,174],{},"这些路径很难在系统设计阶段全部列出。",[60,176,178],{"id":177},"_14-coding-agent-是专业执行器","1.4 Coding Agent 是专业执行器",[10,180,181],{},"Coding Agent 是面向代码仓库的专业 Agent，通常具备：",[92,183,184,187,190,193,196,199],{},[95,185,186],{},"阅读和检索代码。",[95,188,189],{},"编辑文件。",[95,191,192],{},"执行命令。",[95,194,195],{},"编译和运行测试。",[95,197,198],{},"分析失败结果并继续修改。",[95,200,201],{},"生成 Diff 和提交说明。",[10,203,204],{},"开发数字员工不等于 Coding Agent。",[10,206,207],{},"开发数字员工拥有企业身份、项目职责、WorkItem、协作上下文和长期任务状态；Coding Agent 则是它在需要操作代码时调用的专业执行器。",[68,209,212],{"className":210,"code":211,"language":73,"meta":74},[71],"开发数字员工\n├── 企业身份与职责\n├── WorkItem 和 Workflow\n├── 业务上下文\n├── 通用模型推理\n├── 外部系统工具\n└── Coding Agent\n",[76,213,211],{"__ignoreMap":74},[55,215,217],{"id":216},"二让-workflow-与公司流程匹配有什么价值","二、让 Workflow 与公司流程匹配有什么价值",[60,219,221],{"id":220},"_21-把隐性规则变成可执行约束","2.1 把隐性规则变成可执行约束",[10,223,224],{},"企业中存在大量没有被正式写下来的规则：",[92,226,227,230,233,236,239,242],{},[95,228,229],{},"哪个团队负责哪个项目。",[95,231,232],{},"哪类修改需要哪些人员 Review。",[95,234,235],{},"哪些检查通过后才能部署。",[95,237,238],{},"谁可以更新 Bug 状态。",[95,240,241],{},"哪些模块属于高风险范围。",[95,243,244],{},"哪些操作必须经过审批。",[10,246,247],{},"如果这些规则只存在于人的经验中，Agent 很难稳定遵守。",[10,249,250],{},"Workflow 可以将它们表达为：",[68,252,255],{"className":253,"code":254,"language":73,"meta":74},[71],"状态\n+ 进入条件\n+ 权限\n+ 审批点\n+ 超时规则\n+ 验收证据\n",[76,256,254],{"__ignoreMap":74},[10,258,259],{},"这相当于把组织运行方式中最重要的不变量，编译成系统可以执行和验证的规则。",[60,261,263],{"id":262},"_22-协调人agent-与多个系统","2.2 协调人、Agent 与多个系统",[10,265,266],{},"企业研发任务通常同时涉及：",[92,268,269,272,275,278,281,284],{},[95,270,271],{},"开发人员和测试人员。",[95,273,274],{},"开发数字员工。",[95,276,277],{},"云效等工作项系统。",[95,279,280],{},"飞书等协作系统。",[95,282,283],{},"Git、PR\u002FMR 和 Code Review。",[95,285,286],{},"CI\u002FCD 和测试环境。",[10,288,289],{},"Agent 可以完成其中某个复杂步骤，但整个任务还需要回答：",[92,291,292,295,298,301,304,307],{},[95,293,294],{},"当前由谁处理？",[95,296,297],{},"现在正在等待什么？",[95,299,300],{},"外部事件到达后恢复哪个任务？",[95,302,303],{},"超时后如何处理？",[95,305,306],{},"谁对最终结果负责？",[95,308,309],{},"哪个系统保存最终业务状态？",[10,311,312],{},"这些问题属于 Workflow 和 WorkItem，而不是一次模型调用。",[60,314,316],{"id":315},"_23-支撑跨越数天的长期任务","2.3 支撑跨越数天的长期任务",[10,318,319],{},"一个研发任务可能这样运行：",[68,321,324],{"className":322,"code":323,"language":73,"meta":74},[71],"今天完成问题分析\n→ 等待开发人员确认\n→ 明天修改代码\n→ 等待 CI\n→ 等待测试环境部署\n→ 两天后测试人员回归\n",[76,325,323],{"__ignoreMap":74},[10,327,328],{},"模型不需要在这几天中一直运行，也不应该依靠一段聊天历史记住全部状态。",[10,330,331],{},"Workflow 负责保存任务进行到哪里、等待什么事件、已经执行过什么，以及恢复时应该从哪里继续。",[10,333,334],{},"这也是当前 Agent 编排框架重新引入持久状态、人工介入和恢复能力的原因。LangGraph 将自己定位为长时间、有状态 Agent 的编排运行时，允许在同一个图中混合确定性节点与模型节点；Temporal 则强调，即使模型的决定不可预测，已经发生的决定和工具结果仍应持久记录，进程恢复时不需要让模型重新决定一次。",[60,336,338],{"id":337},"_24-建立权限审计和责任边界","2.4 建立权限、审计和责任边界",[10,340,341],{},"Workflow 可以明确：",[92,343,344,347,350,353,356,359],{},[95,345,346],{},"数字员工以什么身份执行。",[95,348,349],{},"它可以访问哪些项目和仓库。",[95,351,352],{},"哪些动作允许自动完成。",[95,354,355],{},"哪些动作需要在线确认。",[95,357,358],{},"哪些动作需要独立审批。",[95,360,361],{},"谁承担最终业务责任。",[10,363,364],{},"Agent 是否能够想到某个操作，与企业是否允许执行该操作，是两个不同问题。",[60,366,368],{"id":367},"_25-形成可分析的过程数据","2.5 形成可分析的过程数据",[10,370,371],{},"当任务通过正式 Workflow 推进后，系统才能准确回答：",[92,373,374,377,380,383,386,389],{},[95,375,376],{},"哪个阶段耗时最长？",[95,378,379],{},"有多少任务在等待人工？",[95,381,382],{},"哪类 Bug 经常被重新打开？",[95,384,385],{},"Agent 在什么步骤经常失败？",[95,387,388],{},"哪些情况需要人工接管？",[95,390,391],{},"哪些检查没有产生实际价值？",[10,393,394],{},"聊天记录可以帮助理解个案，但很难直接替代结构化的流程数据。",[55,396,398],{"id":397},"三流程匹配不等于复制现有流程","三、流程匹配不等于复制现有流程",[10,400,401],{},"与公司流程匹配，并不意味着逐项复制现有的人工操作。在设计企业 Workflow 时，可以将流程内容拆成四类：",[403,404,405,418],"table",{},[406,407,408],"thead",{},[409,410,411,415],"tr",{},[412,413,414],"th",{},"流程内容",[412,416,417],{},"应对方式",[419,420,421,430,438,446],"tbody",{},[409,422,423,427],{},[424,425,426],"td",{},"法规、权限、质量和职责底线",[424,428,429],{},"固化为确定性约束",[409,431,432,435],{},[424,433,434],{},"稳定且重复的正常路径",[424,436,437],{},"自动化编排",[409,439,440,443],{},[424,441,442],{},"依赖语义理解和专业判断的部分",[424,444,445],{},"交给 Agent",[409,447,448,451],{},[424,449,450],{},"历史形成但没有实际价值的步骤",[424,452,453],{},"删除，而不是自动化",[10,455,456],{},"流程设计的目标不是百分之百还原现状，而是：",[29,458,459],{},[10,460,461],{},"保留组织必须遵守的不变量，消除无价值摩擦，把无法预先枚举的判断交给 Agent。",[55,463,465],{"id":464},"四为什么-agent-兴起后工作流产品看起来不再流行","四、为什么 Agent 兴起后，工作流产品看起来不再流行",[10,467,468],{},"目前很难证明工作流自动化本身正在衰退。更准确的判断是：它在产品前台的可见度下降了，但在 Agent 系统后台的重要性反而增加了。",[60,470,472],{"id":471},"_41-agent-销售结果工作流销售搭建过程","4.1 Agent 销售结果，工作流销售搭建过程",[10,474,475],{},"传统工作流产品的典型交互是：",[68,477,480],{"className":478,"code":479,"language":73,"meta":74},[71],"选择触发器\n→ 拖入节点\n→ 配置字段映射\n→ 设置条件\n→ 处理异常\n→ 发布\n",[76,481,479],{"__ignoreMap":74},[10,483,484],{},"用户必须提前知道任务应该如何完成。",[10,486,487],{},"Agent 的入口则更接近：",[29,489,490],{},[10,491,492],{},"帮我处理这个 Bug，并在需要我决定时通知我。",[10,494,495],{},"Agent 承诺的是结果，工作流编排器展示的是实现结果的过程。前者更符合普通用户的心理模型，也更容易成为产品和市场叙事的中心。",[60,497,499],{"id":498},"_42-自然语言降低了自动化门槛","4.2 自然语言降低了自动化门槛",[10,501,502],{},"传统流程编排通常要求用户理解：",[92,504,505,508,511,514,517,520],{},[95,506,507],{},"API 和连接器。",[95,509,510],{},"参数映射。",[95,512,513],{},"数据结构。",[95,515,516],{},"条件表达式。",[95,518,519],{},"错误路径。",[95,521,522],{},"状态管理。",[10,524,525],{},"Agent 允许用户先表达目标，再由模型选择工具、补充参数或询问信息。",[10,527,528],{},"因此，聊天或任务入口逐渐取代流程画布成为前台界面，但后台的连接器、权限、执行记录、重试和状态仍然存在。",[60,530,532],{"id":531},"_43-大模型压缩了语义处理节点","4.3 大模型压缩了语义处理节点",[10,534,535],{},"传统流程可能需要：",[68,537,540],{"className":538,"code":539,"language":73,"meta":74},[71],"关键词匹配\n→ 正则提取字段\n→ 规则分类\n→ 选择负责人\n→ 填充回复模板\n",[76,541,539],{"__ignoreMap":74},[10,543,544],{},"大模型可能通过一次或少量调用完成：",[68,546,549],{"className":547,"code":548,"language":73,"meta":74},[71],"理解消息\n→ 提取信息\n→ 分类\n→ 推荐负责人\n→ 生成回复\n",[76,550,548],{"__ignoreMap":74},[10,552,553],{},"流程图上的节点减少了，难以用规则表达的部分被模型吸收。但模型节点之外的任务创建、权限检查、状态更新、通知和失败恢复依然需要 Workflow。",[60,555,557],{"id":556},"_44-agent-更擅长处理异常和长尾输入","4.4 Agent 更擅长处理异常和长尾输入",[10,559,560],{},"传统工作流最擅长稳定、重复、字段清晰的任务。一旦遇到信息缺失、表达方式变化、多个问题混合、临时选择工具或无法预先枚举的异常，流程分支就会不断膨胀。",[10,562,563],{},"Agent 的核心价值正是处理这种不确定性。",[10,565,566],{},"但“不确定性处理得更好”不等于“确定性执行不再需要”。Agent 能够判断下一步应该创建 PR，不代表它应该直接获得不受限制的代码仓库写权限。",[60,568,570],{"id":569},"_45-工作流产品正在重新包装为-agent-基础设施","4.5 工作流产品正在重新包装为 Agent 基础设施",[10,572,573],{},"当前主流产品正在出现明显融合：",[92,575,576,579,582,585,588],{},[95,577,578],{},"Microsoft Copilot Studio 同时提供确定性的 Agent Flow 和由模型动态规划的生成式编排。",[95,580,581],{},"n8n 既支持 Workflow 调用 Agent，也支持 Agent 将 Workflow 当作工具调用。",[95,583,584],{},"LangGraph 在同一图中混合确定性节点和模型驱动节点。",[95,586,587],{},"Temporal 用持久执行为动态 Agent 提供状态、等待和失败恢复。",[95,589,590],{},"Camunda 将确定性流程、人工任务与 AI Agent 的组合称为 Agentic Orchestration。",[10,592,593],{},"因此，工作流不是消失了，而是从产品名称和交互界面中退到 Agent 的运行底座。",[55,595,597],{"id":596},"五二者不是-a-与-b而是两种控制权分配方式","五、二者不是 A 与 B，而是两种控制权分配方式",[10,599,600],{},"Workflow 和 Agent 的根本差异，可以用两个简化模型表示。",[60,602,604],{"id":603},"_51-workflow-是显式状态转换","5.1 Workflow 是显式状态转换",[68,606,609],{"className":607,"code":608,"language":73,"meta":74},[71],"下一状态 = δ（当前状态，事件，规则）\n",[76,610,608],{"__ignoreMap":74},[10,612,126],{},[68,614,617],{"className":615,"code":616,"language":73,"meta":74},[71],"CI 已通过\n+ 已部署测试环境\n→ 等待测试回归\n",[76,618,616],{"__ignoreMap":74},[10,620,621],{},"转换规则来自业务设计和确定性程序。",[60,623,625],{"id":624},"_52-agent-是运行时行动策略","5.2 Agent 是运行时行动策略",[68,627,630],{"className":628,"code":629,"language":73,"meta":74},[71],"候选行动 = π（任务目标，当前状态，上下文，可用工具）\n",[76,631,629],{"__ignoreMap":74},[10,633,126],{},[68,635,638],{"className":636,"code":637,"language":73,"meta":74},[71],"读取日志\n→ 定位相关模块\n→ 搜索调用链\n→ 修改代码\n→ 选择测试\n",[76,639,637],{"__ignoreMap":74},[10,641,642],{},"这些步骤由模型根据任务上下文动态决定。",[60,644,646],{"id":645},"_53-企业系统需要在两者之间增加验证层","5.3 企业系统需要在两者之间增加验证层",[68,648,651],{"className":649,"code":650,"language":73,"meta":74},[71],"Agent 提出候选行动\n          │\n          ▼\nWorkflow \u002F Policy 验证\n├── 允许：执行并记录结果\n├── 需要审批：暂停等待人工\n└── 拒绝：返回 Agent 重新规划\n",[76,652,650],{"__ignoreMap":74},[10,654,655],{},"也就是说：",[29,657,658],{},[10,659,660],{},"Agent 决定“建议做什么”，Workflow 决定“是否允许这样做，以及做完以后任务进入什么状态”。",[10,662,663],{},"二者不是同一层面的竞争关系。Agent 提供运行时判断能力，Workflow 提供组织约束和可靠执行能力。",[55,665,667],{"id":666},"六workflow-与-agent-的四种组合方式","六、Workflow 与 Agent 的四种组合方式",[60,669,671],{"id":670},"_61-workflow-调用-agent","6.1 Workflow 调用 Agent",[68,673,676],{"className":674,"code":675,"language":73,"meta":74},[71],"接收反馈\n→ 调用 Agent 识别是否为 Bug\n→ 获得结构化判断\n→ 程序创建或关联 WorkItem\n",[76,677,675],{"__ignoreMap":74},[10,679,680],{},"外层路径固定，某个需要语义理解的节点由 Agent 完成。这是大多数企业场景最容易控制的方式。",[60,682,684],{"id":683},"_62-agent-调用-workflow","6.2 Agent 调用 Workflow",[68,686,689],{"className":687,"code":688,"language":73,"meta":74},[71],"Agent 判断需要创建 Draft PR\n→ 调用“创建 Draft PR”工作流\n→ 工作流完成权限、参数、幂等和结果确认\n",[76,690,688],{"__ignoreMap":74},[10,692,693],{},"这是一种非常重要的安全模式。",[10,695,696],{},"Agent 不直接持有宽泛的 Git 写权限，而是获得一个语义明确、能力受限的工具。n8n 给出的类似例子是：Agent 不直接获得 CRM 写权限，而是调用一个只能添加备注的工作流。",[60,698,700],{"id":699},"_63-workflow-中包含-agent-子流程","6.3 Workflow 中包含 Agent 子流程",[68,702,705],{"className":703,"code":704,"language":73,"meta":74},[71],"进入“问题诊断”状态\n→ Agent 自主循环：\n   查日志 → 读代码 → 提出假设 → 验证\n→ 输出诊断结果\n→ 返回主流程\n",[76,706,704],{"__ignoreMap":74},[10,708,709],{},"外层业务生命周期确定，局部探索过程动态。",[60,711,713],{"id":712},"_64-agent-在运行时组合多个-workflow","6.4 Agent 在运行时组合多个 Workflow",[68,715,718],{"className":716,"code":717,"language":73,"meta":74},[71],"Agent 根据目标选择：\n├── 查询相关 Bug\n├── 获取日志\n├── 启动代码修改\n├── 创建 Draft PR\n└── 通知负责人\n",[76,719,717],{"__ignoreMap":74},[10,721,722],{},"Agent 是规划者，Workflow 则成为安全、稳定、可复用的企业技能。",[10,724,725],{},"这四种方式可以同时存在。真正需要选择的，不是整个系统使用 Workflow 还是 Agent，而是每一个控制点的决定权应该放在哪里。",[55,727,729],{"id":728},"七如何判断一个步骤应该交给谁","七、如何判断一个步骤应该交给谁",[10,731,732],{},"可以从五个维度判断：",[403,734,735,748],{},[406,736,737],{},[409,738,739,742,745],{},[412,740,741],{},"判断维度",[412,743,744],{},"更适合 Workflow",[412,746,747],{},"更适合 Agent",[419,749,750,761,772,783,794],{},[409,751,752,755,758],{},[424,753,754],{},"输入",[424,756,757],{},"结构化、字段明确",[424,759,760],{},"自然语言、多来源、信息不完整",[409,762,763,766,769],{},[424,764,765],{},"路径",[424,767,768],{},"可以预先枚举",[424,770,771],{},"依赖运行时探索",[409,773,774,777,780],{},[424,775,776],{},"结果",[424,778,779],{},"可以用规则精确判断",[424,781,782],{},"需要语义或专业判断",[409,784,785,788,791],{},[424,786,787],{},"风险",[424,789,790],{},"高风险、强合规",[424,792,793],{},"低风险或有外层约束",[409,795,796,799,802],{},[424,797,798],{},"频率",[424,800,801],{},"高频、重复、稳定",[424,803,804],{},"长尾、变化多、异常多",[10,806,807],{},"一个实用原则是：",[68,809,812],{"className":810,"code":811,"language":73,"meta":74},[71],"高确定性 + 高风险 + 强审计\n→ Workflow 占比更高\n\n开放输入 + 难预测路径 + 依赖语义判断\n→ Agent 占比更高\n",[76,813,811],{"__ignoreMap":74},[10,815,816],{},"如果某一步虽然需要模型判断，但会产生高风险副作用，可以采用：",[68,818,821],{"className":819,"code":820,"language":73,"meta":74},[71],"Agent 生成建议\n→ Workflow 校验\n→ 人工审批\n→ 确定性执行\n",[76,822,820],{"__ignoreMap":74},[55,824,826],{"id":825},"八开发数字员工中的具体分工","八、开发数字员工中的具体分工",[60,828,830],{"id":829},"_81-外层生命周期由-workflow-管理","8.1 外层生命周期由 Workflow 管理",[10,832,833],{},"第一个主动式 Bug 闭环可以表示为：",[68,835,838],{"className":836,"code":837,"language":73,"meta":74},[71],"收到飞书反馈或云效事件\n→ 验签、去重\n→ 创建或关联 WorkItem\n→ 确认项目与权限\n→ 分配开发数字员工\n→ 等待分析结果\n→ 等待代码与测试\n→ 等待人工 Review\n→ 等待 CI\n→ 等待测试环境部署\n→ 标记 Bug 已修复\n→ 等待测试回归\n→ 关闭或重新打开\n",[76,839,837],{"__ignoreMap":74},[10,841,842],{},"这些步骤涉及企业状态、权限、等待和责任，应当由确定性程序管理。",[60,844,846],{"id":845},"_82-内部探索由-agent-完成","8.2 内部探索由 Agent 完成",[10,848,849],{},"开发数字员工中的通用模型可以负责：",[92,851,852,855,858,861,864,867,870,873,876,879],{},[95,853,854],{},"理解飞书消息和任务意图。",[95,856,857],{},"提取项目、模块、接口和环境信息。",[95,859,860],{},"判断信息是否足够。",[95,862,863],{},"查找候选重复问题。",[95,865,866],{},"分析需求和技术文档。",[95,868,869],{},"设计技术方案。",[95,871,872],{},"规划排查路径。",[95,874,875],{},"诊断问题和生成修复计划。",[95,877,878],{},"选择需要调用的工具。",[95,880,881],{},"总结结果、风险和下一步。",[60,883,885],{"id":884},"_83-代码操作交给-coding-agent","8.3 代码操作交给 Coding Agent",[10,887,888,889,892],{},"当任务进入代码执行阶段时，开发数字员工通过 ",[76,890,891],{},"CodingAgentProvider"," 提交受约束的代码任务：",[68,894,897],{"className":895,"code":896,"language":73,"meta":74},[71],"WorkItem\n→ Context Builder 生成任务上下文\n→ 创建隔离工作区\n→ 调用 Coding Agent\n→ 阅读与修改代码\n→ 编译和运行测试\n→ 返回 Diff、日志和测试结果\n",[76,898,896],{"__ignoreMap":74},[10,900,901],{},"Coding Agent 可以自主决定修改哪些文件、运行哪些命令，但它不能自行决定是否拥有目标仓库权限，也不能自行宣布业务任务已经完成。",[60,903,905],{"id":904},"_84-外部副作用通过受限工具暴露","8.4 外部副作用通过受限工具暴露",[10,907,908],{},"不应直接给 Agent 一个宽泛的“调用云效 API”或“执行 Git 命令”工具，而应提供语义明确的能力：",[68,910,913],{"className":911,"code":912,"language":73,"meta":74},[71],"findRelatedBugs()\ncreateOrLinkWorkItem()\naddBugComment()\ncreateDraftPullRequest()\nrequestCodeReview()\nmarkBugFixed()\nnotifyOwner()\n",[76,914,912],{"__ignoreMap":74},[10,916,917],{},"每个工具内部负责：",[92,919,920,923,926,929,932,935],{},[95,921,922],{},"身份与权限。",[95,924,925],{},"参数校验。",[95,927,928],{},"幂等。",[95,930,931],{},"重试。",[95,933,934],{},"外部结果确认。",[95,936,937],{},"审计记录。",[10,939,940],{},"这样 Agent 可以灵活规划，却无法绕过企业约束。",[55,942,944],{"id":943},"九一个更具体的运行模型","九、一个更具体的运行模型",[10,946,947],{},"开发数字员工处理任务时，可以形成如下循环：",[68,949,952],{"className":950,"code":951,"language":73,"meta":74},[71],"1. Workflow 激活 WorkItem\n2. Context Builder 构建本轮上下文\n3. Agent 输出结构化候选行动\n4. Policy 检查权限、风险和前置条件\n5. Executor 或 Coding Agent 执行\n6. 外部系统返回真实结果\n7. 结果写入 Run、Artifact、Evidence 和 DomainEvent\n8. Workflow 根据结果推进、等待或重新调度\n",[76,953,951],{"__ignoreMap":74},[10,955,956],{},"Agent 的输出不应只是自然语言，而应尽可能结构化：",[68,958,961],{"className":959,"code":960,"language":73,"meta":74},[71],"AgentDecision\n├── intent\n├── proposedAction\n├── target\n├── parameters\n├── rationale\n├── contextReferences\n├── riskLevel\n└── requiredApproval\n",[76,962,960],{"__ignoreMap":74},[10,964,965],{},"Policy 层再返回：",[68,967,970],{"className":968,"code":969,"language":73,"meta":74},[71],"PolicyDecision\n├── allow\n├── denyReason\n├── approvalRequired\n├── preconditions\n└── idempotencyKey\n",[76,971,969],{"__ignoreMap":74},[10,973,974],{},"这使模型判断、企业规则和实际执行可以分别测试和审计。",[55,976,978],{"id":977},"十总结用-workflow-表达不变量用-agent-处理不确定性","十、总结：用 Workflow 表达不变量，用 Agent 处理不确定性",[10,980,981],{},"Workflow 与 Agent 不是两种互斥的产品，也不是简单的新旧技术替代关系。",[10,983,984],{},"它们代表的是两种不同的控制方式：",[92,986,987,990,993,996,999],{},[95,988,989],{},"Workflow 将组织已经明确的规则转化为可执行状态。",[95,991,992],{},"Agent 根据运行时上下文处理无法预先枚举的问题。",[95,994,995],{},"Coding Agent 在受控工作区内执行专业代码任务。",[95,997,998],{},"Policy 和 Approval 决定候选行动能否产生真实副作用。",[95,1000,1001],{},"外部企业系统保存最终业务事实。",[10,1003,1004],{},"通用 Agent 的兴起，没有消灭工作流。它只是让工作流从用户直接操作的前台产品，逐渐转化为 Agent 背后的任务、权限和可靠执行底座。",[10,1006,1007],{},"对于开发数字员工而言，合理的系统不是让 Agent 自由操作所有系统，也不是把它限制在一条完全固定的脚本中，而是：",[29,1009,1010],{},[10,1011,1012],{},"用 Workflow 表达组织的不变量，用 Agent 处理运行时的不确定性；让 Agent 可以选择经过治理的 Workflow，让 Workflow 可以在需要判断的节点调用 Agent。",[10,1014,1015],{},"Agent 越接近真正的企业员工，越需要 Workflow 为它提供任务状态、权限、审批、等待恢复、审计和责任边界。",[10,1017,1018,1019],{},"下一篇将进一步进入开发人员工作台的实现：",[19,1020,1021],{},"如何用 WorkItem 状态机、Timeline、Evidence 和 Approval 建立一个无需 Agent 也能运行的领域骨架。",[55,1023,1024],{"id":1024},"参考资料",[1026,1027,1028,1038,1046,1054,1062,1070,1078,1086],"ol",{},[95,1029,1030,1037],{},[1031,1032,1036],"a",{"href":1033,"rel":1034},"https:\u002F\u002Fwww.anthropic.com\u002Fresearch\u002Fbuilding-effective-agents",[1035],"nofollow","Anthropic：Building effective agents"," — 区分预定义路径的 Workflow 与模型动态控制的 Agent，并讨论各自适用场景。",[95,1039,1040,1045],{},[1031,1041,1044],{"href":1042,"rel":1043},"https:\u002F\u002Flearn.microsoft.com\u002Fmicrosoft-copilot-studio\u002Fflows-overview",[1035],"Microsoft Copilot Studio：Agent flows overview"," — 确定性 Agent Flow、人工介入、连接器和流程可见性。",[95,1047,1048,1053],{},[1031,1049,1052],{"href":1050,"rel":1051},"https:\u002F\u002Flearn.microsoft.com\u002Fmicrosoft-copilot-studio\u002Fguidance\u002Fgenerative-orchestration",[1035],"Microsoft Copilot Studio：Apply generative orchestration capabilities"," — 生成式规划、工具调用、控制边界和审批方式。",[95,1055,1056,1061],{},[1031,1057,1060],{"href":1058,"rel":1059},"https:\u002F\u002Fn8n.io\u002Fblog\u002Fintroducing-n8n-agents",[1035],"n8n：Introducing n8n Agents"," — Agent 调用 Workflow、Workflow 调用 Agent，以及凭证和审批边界。",[95,1063,1064,1069],{},[1031,1065,1068],{"href":1066,"rel":1067},"https:\u002F\u002Fdocs.langchain.com\u002Foss\u002Fpython\u002Flanggraph\u002Foverview",[1035],"LangGraph overview"," — 混合确定性步骤和模型步骤的长时间、有状态 Agent 编排运行时。",[95,1071,1072,1077],{},[1031,1073,1076],{"href":1074,"rel":1075},"https:\u002F\u002Fwww.langchain.com\u002Fblog\u002Fwhat-is-an-agent",[1035],"LangChain：What is an AI agent?"," — 从模型拥有多少控制流解释 Agent 的自主程度。",[95,1079,1080,1085],{},[1031,1081,1084],{"href":1082,"rel":1083},"https:\u002F\u002Ftemporal.io\u002Fblog\u002Fof-course-you-can-build-dynamic-ai-agents-with-temporal",[1035],"Temporal：Of course you can build dynamic AI agents with Temporal"," — 非确定性 Agent 决策与确定性、可恢复执行之间的关系。",[95,1087,1088,1093],{},[1031,1089,1092],{"href":1090,"rel":1091},"https:\u002F\u002Fcamunda.com\u002Fblog\u002F2026\u002F04\u002Fcase-for-a-central-business-orchestration-layer-without-recentralizing-your-architecture",[1035],"Camunda：The Case for a Central Business Orchestration Layer"," — 在同一业务编排中组合确定性流程、人工判断和不同自主程度的 Agent。",{"title":74,"searchDepth":1095,"depth":1095,"links":1096},2,[1097,1104,1111,1112,1119,1124,1130,1131,1137,1138,1139],{"id":57,"depth":1095,"text":58,"children":1098},[1099,1101,1102,1103],{"id":62,"depth":1100,"text":63},3,{"id":83,"depth":1100,"text":84},{"id":138,"depth":1100,"text":139},{"id":177,"depth":1100,"text":178},{"id":216,"depth":1095,"text":217,"children":1105},[1106,1107,1108,1109,1110],{"id":220,"depth":1100,"text":221},{"id":262,"depth":1100,"text":263},{"id":315,"depth":1100,"text":316},{"id":337,"depth":1100,"text":338},{"id":367,"depth":1100,"text":368},{"id":397,"depth":1095,"text":398},{"id":464,"depth":1095,"text":465,"children":1113},[1114,1115,1116,1117,1118],{"id":471,"depth":1100,"text":472},{"id":498,"depth":1100,"text":499},{"id":531,"depth":1100,"text":532},{"id":556,"depth":1100,"text":557},{"id":569,"depth":1100,"text":570},{"id":596,"depth":1095,"text":597,"children":1120},[1121,1122,1123],{"id":603,"depth":1100,"text":604},{"id":624,"depth":1100,"text":625},{"id":645,"depth":1100,"text":646},{"id":666,"depth":1095,"text":667,"children":1125},[1126,1127,1128,1129],{"id":670,"depth":1100,"text":671},{"id":683,"depth":1100,"text":684},{"id":699,"depth":1100,"text":700},{"id":712,"depth":1100,"text":713},{"id":728,"depth":1095,"text":729},{"id":825,"depth":1095,"text":826,"children":1132},[1133,1134,1135,1136],{"id":829,"depth":1100,"text":830},{"id":845,"depth":1100,"text":846},{"id":884,"depth":1100,"text":885},{"id":904,"depth":1100,"text":905},{"id":943,"depth":1095,"text":944},{"id":977,"depth":1095,"text":978},{"id":1024,"depth":1095,"text":1024},"wiki:agent:developer-digital-employee-workflow-agent-coding-agent-boundaries",false,"md",{},true,"\u002Fagent\u002Fdeveloper-digital-employee-workflow-agent-coding-agent-boundaries","企业级 Agent",{"title":5,"description":15},"agent\u002Fdeveloper-digital-employee-workflow-agent-coding-agent-boundaries","2026-11-11","0Q-dTdUiOp_ZilgoRHD2LQKBFdvdMSQBrAl4gXG0U4Y",[1152,3144,4344,5128],{"id":1153,"title":1154,"body":1155,"commentId":3136,"description":1161,"draft":1141,"extension":1142,"meta":3137,"navigation":1144,"order":3138,"path":3139,"section":1146,"seo":3140,"stem":3141,"updated":3142,"__hash__":3143},"agent\u002Fagent\u002Fenterprise-ai-agent-system-requirements-challenges-architecture.md","企业级 AI Agent 系统：需求分析、核心挑战与架构设计目标",{"type":7,"value":1156,"toc":3093},[1157,1162,1167,1171,1174,1177,1180,1183,1188,1192,1195,1198,1205,1208,1222,1225,1230,1233,1265,1272,1275,1279,1282,1285,1314,1317,1322,1325,1328,1333,1336,1340,1343,1346,1350,1357,1374,1377,1385,1388,1395,1398,1503,1506,1509,1514,1517,1521,1524,1528,1531,1534,1537,1540,1557,1560,1567,1571,1574,1577,1579,1582,1585,1588,1602,1607,1614,1618,1621,1624,1627,1630,1633,1638,1645,1649,1656,1659,1662,1665,1672,1676,1679,1684,1687,1692,1695,1700,1703,1708,1711,1714,1717,1721,1724,1728,1731,1734,1736,1753,1756,1759,1779,1782,1787,1790,1793,1797,1800,1803,1805,1819,1822,1828,1834,1837,1840,1843,1846,1850,1853,1856,1859,1879,1882,1899,1902,1905,1908,1913,1916,1921,1924,1929,1932,1937,1940,1946,1949,1952,1956,1959,1962,1988,1991,1996,1999,2002,2019,2022,2026,2029,2032,2055,2058,2063,2066,2071,2074,2079,2082,2087,2090,2093,2098,2102,2105,2107,2124,2127,2130,2153,2156,2167,2170,2173,2178,2181,2185,2188,2191,2196,2199,2202,2205,2211,2217,2223,2226,2230,2233,2236,2298,2301,2304,2307,2312,2315,2318,2322,2325,2330,2333,2336,2342,2345,2349,2352,2358,2361,2399,2403,2408,2411,2416,2419,2424,2427,2430,2434,2440,2443,2446,2450,2544,2547,2551,2554,2558,2561,2578,2581,2585,2588,2611,2614,2618,2621,2644,2647,2651,2654,2674,2678,2681,2791,2794,2797,2801,2804,2807,2813,2819,2825,2831,2837,2843,2849,2855,2859,2862,2865,2868,2873,2876,2881,2884,2889,2892,2897,2900,2905,2908,2913,2916,2919,2936,2940,2943,2948,2951,2954,2957,2985,2988,2991,2994,2997,3002,3004,3007,3082,3085,3090],[10,1158,1159],{},[13,1160,1161],{},"以智能开发人员工作台为近期实践载体，探索研发任务、主动式 Bug 闭环与企业级数字员工的演进路径。",[10,1163,1164],{},[19,1165,1166],{},"系列：从零构建企业级 AI Agent · 第 01 篇",[55,1168,1170],{"id":1169},"一引言通用-agent-已经很强为什么还要自己开发","一、引言：通用 Agent 已经很强，为什么还要自己开发？",[10,1172,1173],{},"随着大模型能力不断提升，AI Agent 正在从简单的对话助手，演进为能够理解任务、调用工具、执行操作的智能系统。",[10,1175,1176],{},"今天，通用 Agent 已经能够完成相当复杂的工作，例如编写代码、分析文档、搜索资料、操作软件，甚至连续执行多步骤任务。",[10,1178,1179],{},"与此同时，LangGraph、OpenAI Agents SDK 等开发框架，以及各类企业 Agent 平台，也在不断降低 Agent 的开发门槛。",[10,1181,1182],{},"这引出了一个值得思考的问题：",[10,1184,1185],{},[19,1186,1187],{},"既然通用 Agent 已经如此强大，企业为什么还需要建设自己的 Agent？",[60,1189,1191],{"id":1190},"_11-从研发全流程与测试反馈说起","1.1 从研发全流程与测试反馈说起",[10,1193,1194],{},"后端研发通常经历需求分析、技术方案设计、开发与自测、Code Review、提测、测试、上线准备和发布等环节。",[10,1196,1197],{},"今天的 AI 工具已经能够分别辅助其中许多步骤：阅读需求、生成技术方案、编写代码、补充测试、分析日志和执行代码检查。但在实际工作中，开发人员仍需要反复搬运需求、文档、代码、日志和测试反馈，并在不同工具之间维护任务状态。",[10,1199,1200,1201,1204],{},"更理想的产品形态不是增加一个孤立的聊天窗口，而是建设一个",[19,1202,1203],{},"以研发任务为中心的智能开发人员工作台","。它持续组织一个任务从需求到交付的上下文、产物、执行过程和验收证据，并在关键节点保留人工确认。",[10,1206,1207],{},"测试阶段的 Bug 处理，是这个工作台最适合率先验证的主动式闭环。假设研发团队日常使用：",[92,1209,1210,1213,1216,1219],{},[95,1211,1212],{},"云效：管理需求、Bug 和研发任务。",[95,1214,1215],{},"飞书：测试人员反馈问题、研发人员讨论和协作。",[95,1217,1218],{},"GitLab：托管代码、管理 Merge Request。",[95,1220,1221],{},"CI 平台：执行单元测试、集成测试和代码检查。",[10,1223,1224],{},"开发人员完成 Code Review 并提测后，测试人员可能在飞书群中反馈：",[29,1226,1227],{},[10,1228,1229],{},"订单服务的退款接口偶尔返回 500，云效上之前好像也提过这个问题，麻烦后端看一下。",[10,1231,1232],{},"此时，Agent 可以在授权范围内主动完成：",[1026,1234,1235,1238,1241,1244,1247,1250,1253,1256,1259,1262],{},[95,1236,1237],{},"识别潜在的 Bug 反馈，保留消息来源和上下文。",[95,1239,1240],{},"查询云效，判断是否已经存在相同或相关缺陷。",[95,1242,1243],{},"关联原始需求、代码分支、Commit、负责人和测试环境。",[95,1245,1246],{},"检索相关代码、日志、技术文档与经过验证的历史修复记录。",[95,1248,1249],{},"分析原因，创建受控修复分支，修改代码并运行测试。",[95,1251,1252],{},"创建 Draft PR\u002FMR，附上问题分析、修改内容、测试结果和剩余风险。",[95,1254,1255],{},"跟踪必要的增量 Code Review、CI 和测试环境部署状态。",[95,1257,1258],{},"满足预设条件后，将云效 Bug 标记为“已修复”，等待测试人员回归验证。",[95,1260,1261],{},"如果回归失败，则重新打开并继续原任务；验证通过后关闭 Bug。",[95,1263,1264],{},"将经过回归验证的修复经验沉淀为候选团队知识。",[10,1266,1267,1268,1271],{},"这不再是一次简单问答，而是一个",[19,1269,1270],{},"由测试反馈触发、跨越多套系统、能够等待人工与外部事件并持续恢复执行的长期研发任务","。",[10,1273,1274],{},"需要强调：自动处理测试阶段 Bug 不是项目的全部。近期产品形态是开发人员工作台，研发全流程是领域边界，Bug 处理是第一个主动式闭环，企业级数字员工则是长期架构方向。",[60,1276,1278],{"id":1277},"_12-通用-agent-与企业-agent-的关键区别","1.2 通用 Agent 与企业 Agent 的关键区别",[10,1280,1281],{},"对于通用模型而言，理解 Bug 描述、分析代码甚至生成补丁，都已经是相对成熟的能力。",[10,1283,1284],{},"真正困难的是：",[92,1286,1287,1290,1293,1296,1299,1302,1305,1308,1311],{},[95,1288,1289],{},"Agent 如何持续感知企业内部发生的事件？",[95,1291,1292],{},"如何获得飞书、云效和代码仓库的访问权限？",[95,1294,1295],{},"如何知道哪个项目、哪个模块属于哪个负责人？",[95,1297,1298],{},"如何避免对同一个 Bug 重复创建任务或 PR？",[95,1300,1301],{},"如何在多个 Agent 之间共享任务上下文？",[95,1303,1304],{},"如何利用历史修复经验，同时避免错误记忆影响判断？",[95,1306,1307],{},"如何在执行中断后恢复任务？",[95,1309,1310],{},"如何保证代码修改不会越过企业的安全边界？",[95,1312,1313],{},"如何验证 Agent 真的修复了 Bug，而不只是提交了一段代码？",[10,1315,1316],{},"这些问题已经超出了单纯的模型推理能力。",[10,1318,1319],{},[19,1320,1321],{},"通用模型解决的是智能能力的供给问题，企业 Agent 还需要解决智能能力如何融入组织、业务流程与软件工程体系的问题。",[10,1323,1324],{},"因此，企业需要的通常不是重新训练一个更聪明的模型，而是建设能够整合内部系统、理解业务上下文、执行长期任务并接受治理的 Agent 能力。",[10,1326,1327],{},"但需要强调：",[10,1329,1330],{},[19,1331,1332],{},"企业拥有自己的 Agent 能力，不等于必须从零自研 Agent Runtime。",[10,1334,1335],{},"采购成熟产品、基于现有平台定制、使用开源框架开发以及自研核心组件，都是合理选择。",[55,1337,1339],{"id":1338},"二市场需求企业究竟在招聘什么样的-agent-工程师","二、市场需求：企业究竟在招聘什么样的 Agent 工程师？",[10,1341,1342],{},"判断一项技术的实际需求，不能只看技术社区的热度，还需要观察企业愿意投入哪些研发资源。",[10,1344,1345],{},"招聘信息是一个有价值的观察窗口。",[60,1347,1349],{"id":1348},"_21-从企业招聘-jd-看-agent-技术能力","2.1 从企业招聘 JD 看 Agent 技术能力",[10,1351,1352,1353,1356],{},"以滴滴官方招聘岗位 ",[19,1354,1355],{},"AI Agent 基建平台架构师"," 为例，岗位职责涉及：",[92,1358,1359,1362,1365,1368,1371],{},[95,1360,1361],{},"Agent 创建、配置、版本、发布及运行托管等全生命周期管理。",[95,1363,1364],{},"Agent 编排与运行时能力，包括模型、Prompt、知识库、MCP、工作流、记忆和任务调度。",[95,1366,1367],{},"日志追踪、异常恢复、灰度发布、权限隔离和稳定性建设。",[95,1369,1370],{},"高并发、分布式运行时的性能优化。",[95,1372,1373],{},"评估 LangGraph、DeepAgents 等框架，并结合业务进行技术选型。",[10,1375,1376],{},"这些要求说明，企业正在将 Agent 视为一种需要长期维护的软件系统，而不仅仅是一次模型 API 调用。",[10,1378,1379,1380],{},"资料来源：",[1031,1381,1384],{"href":1382,"rel":1383},"https:\u002F\u002Ftalent.didiglobal.com\u002Fsocial\u002FjobDetail?jdId=66598",[1035],"滴滴招聘——AI Agent 基建平台架构师",[10,1386,1387],{},"京东的 Agent 平台方向岗位也涉及业务 Agent、工具集成、MCP、Agent 协作及工程问题定位。",[10,1389,1379,1390],{},[1031,1391,1394],{"href":1392,"rel":1393},"https:\u002F\u002Fzhaopin.jd.com\u002Fweb\u002Fjob-info-detail?requementId=226656",[1035],"京东招聘——Agent 平台方向",[10,1396,1397],{},"结合部分公开岗位描述，可以将相关研发需求归纳为以下几类：",[403,1399,1400,1413],{},[406,1401,1402],{},[409,1403,1404,1407,1410],{},[412,1405,1406],{},"能力领域",[412,1408,1409],{},"典型技术要求",[412,1411,1412],{},"对应的企业问题",[419,1414,1415,1426,1437,1448,1459,1470,1481,1492],{},[409,1416,1417,1420,1423],{},[424,1418,1419],{},"Agent Runtime",[424,1421,1422],{},"Loop、编排、状态、调度",[424,1424,1425],{},"如何持续执行复杂任务",[409,1427,1428,1431,1434],{},[424,1429,1430],{},"Tool \u002F MCP",[424,1432,1433],{},"工具发现、调用、权限",[424,1435,1436],{},"如何连接企业业务系统",[409,1438,1439,1442,1445],{},[424,1440,1441],{},"Memory \u002F RAG",[424,1443,1444],{},"长期记忆、知识检索",[424,1446,1447],{},"如何使用企业知识和历史经验",[409,1449,1450,1453,1456],{},[424,1451,1452],{},"Multi-Agent",[424,1454,1455],{},"任务分解、协作、交接",[424,1457,1458],{},"如何协调不同职责",[409,1460,1461,1464,1467],{},[424,1462,1463],{},"Security",[424,1465,1466],{},"身份、授权、审计",[424,1468,1469],{},"如何防止越权与数据泄露",[409,1471,1472,1475,1478],{},[424,1473,1474],{},"Reliability",[424,1476,1477],{},"幂等、恢复、容错",[424,1479,1480],{},"如何保证业务操作可靠",[409,1482,1483,1486,1489],{},[424,1484,1485],{},"Evaluation",[424,1487,1488],{},"任务评测、Trace、监控",[424,1490,1491],{},"如何判断 Agent 是否有效",[409,1493,1494,1497,1500],{},[424,1495,1496],{},"Platform Engineering",[424,1498,1499],{},"部署、版本、灰度、成本",[424,1501,1502],{},"如何让多个团队持续使用",[10,1504,1505],{},"以上是对部分公开招聘样本的定性分析，不是经过统计抽样的全市场岗位占比结论。岗位发布也不能直接证明相关能力已经在企业内部成熟落地。",[10,1507,1508],{},"不过，这些需求揭示了一个重要趋势：",[10,1510,1511],{},[19,1512,1513],{},"Agent 开发正在从模型调用和 Prompt 设计，向运行时、数据工程、权限治理和软件可靠性等方向延伸。",[10,1515,1516],{},"对于具有传统后端、分布式系统和企业业务研发经验的工程师，这些领域同样是进入 Agent 工程的重要切入点。",[55,1518,1520],{"id":1519},"三大厂实践企业-agent-平台正在解决什么问题","三、大厂实践：企业 Agent 平台正在解决什么问题？",[10,1522,1523],{},"招聘需求反映企业希望获得的研发能力，而云平台和企业软件厂商的公开架构，则展示了另一种视角：当 Agent 被广泛引入企业时，需要补充哪些基础设施？",[60,1525,1527],{"id":1526},"_31-google-cloud从模型平台到-agent-平台","3.1 Google Cloud：从模型平台到 Agent 平台",[10,1529,1530],{},"Google Cloud 在 Gemini Enterprise Agent Platform 中，将平台能力概括为构建、规模化运行、治理和优化 Agent。",[10,1532,1533],{},"除了模型本身，平台还强调 Agent Identity、Registry、Gateway、Memory、Evaluation 和 Observability 等能力。",[10,1535,1536],{},"当企业只有一个 Agent 时，开发者可能只需要关注模型、工具和 Prompt。",[10,1538,1539],{},"当企业拥有大量 Agent 时，就需要回答：",[92,1541,1542,1545,1548,1551,1554],{},[95,1543,1544],{},"Agent 由谁创建和管理？",[95,1546,1547],{},"哪个 Agent 可以访问哪些工具？",[95,1549,1550],{},"Agent 的身份和权限如何维护？",[95,1552,1553],{},"如何追踪一次跨系统任务？",[95,1555,1556],{},"如何统一评估、部署和更新？",[10,1558,1559],{},"这些问题更接近平台工程，而不是单个 AI 应用的开发。",[10,1561,1379,1562],{},[1031,1563,1566],{"href":1564,"rel":1565},"https:\u002F\u002Fcloud.google.com\u002Fblog\u002Fproducts\u002Fai-machine-learning\u002Fintroducing-gemini-enterprise-agent-platform",[1035],"Google Cloud——Introducing Gemini Enterprise Agent Platform",[60,1568,1570],{"id":1569},"_32-microsoftagent-需要自己的身份和治理机制","3.2 Microsoft：Agent 需要自己的身份和治理机制",[10,1572,1573],{},"Microsoft 的 Agent 相关架构强调 Agent Identity、委托授权以及企业治理。",[10,1575,1576],{},"传统企业软件主要管理人的身份和权限。Agent 出现之后，企业需要进一步考虑：一个由用户发起、可能持续执行并调用多个系统的 Agent，究竟应该以什么身份行动？",[10,1578,126],{},[10,1580,1581],{},"研发人员 A 可以查看自己负责的代码仓库，但不能访问其他团队的私有仓库。",[10,1583,1584],{},"当研发人员 A 委托 Coding Agent 修复 Bug 时，Coding Agent 不应该因为自身拥有代码工具，就自动获得修改所有仓库的权限。",[10,1586,1587],{},"因此，需要区分：",[92,1589,1590,1593,1596,1599],{},[95,1591,1592],{},"用户身份与用户权限。",[95,1594,1595],{},"Agent 身份与 Agent 自身的能力范围。",[95,1597,1598],{},"用户授予 Agent 的委托权限。",[95,1600,1601],{},"目标业务系统最终执行的授权校验。",[10,1603,1604],{},[19,1605,1606],{},"Agent 的执行权限不应该由模型通过 Prompt 自行决定。",[10,1608,1379,1609],{},[1031,1610,1613],{"href":1611,"rel":1612},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fmicrosoft-agent-365\u002Fbuilder\u002Fidentity",[1035],"Microsoft Agent 365——Agent Identity",[60,1615,1617],{"id":1616},"_33-aws工具调用需要独立的策略执行边界","3.3 AWS：工具调用需要独立的策略执行边界",[10,1619,1620],{},"AWS Bedrock AgentCore 的 Gateway 和策略机制强调，对 Agent 工具调用进行独立授权和拦截。",[10,1622,1623],{},"原因很直接：Agent 的工具调用具有一定动态性。",[10,1625,1626],{},"同样一个用户请求，模型可能选择不同工具、不同参数和不同执行顺序。",[10,1628,1629],{},"因此，系统不能仅仅通过一段 System Prompt 告诉模型“不要执行危险操作”，就认为安全问题已经解决。",[10,1631,1632],{},"更合理的设计是：",[10,1634,1635],{},[19,1636,1637],{},"模型负责提出行动，程序负责验证行动，业务系统负责维护最终业务约束。",[10,1639,1379,1640],{},[1031,1641,1644],{"href":1642,"rel":1643},"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fmachine-learning\u002Fsecure-ai-agents-with-policy-and-lambda-interceptors-in-amazon-bedrock-agentcore-gateway\u002F",[1035],"AWS——Securing AI Agents with AgentCore Gateway Policies",[60,1646,1648],{"id":1647},"_34-salesforceagent-是企业-it-架构的组成部分","3.4 Salesforce：Agent 是企业 IT 架构的组成部分",[10,1650,1651,1652,1655],{},"Salesforce 在 ",[13,1653,1654],{},"The Agentic Enterprise"," 架构中，将 Agent Runtime、企业语义层、应用集成、工作流编排、可观测性和安全治理放在统一架构下讨论。",[10,1657,1658],{},"传统企业系统主要围绕人使用应用程序开展工作，而 Agent 使软件能够在授权范围内参与任务判断与执行。",[10,1660,1661],{},"但企业原有的 ERP、CRM、财务和订单系统并不会因此消失。",[10,1663,1664],{},"Agent 更可能通过标准化接口和业务服务与这些系统协作，而不是直接取代所有既有业务逻辑。",[10,1666,1379,1667],{},[1031,1668,1671],{"href":1669,"rel":1670},"https:\u002F\u002Farchitect.salesforce.com\u002Fdocs\u002Farchitect\u002Ffundamentals\u002Fguide\u002Fagentic-enterprise-it-architecture",[1035],"Salesforce Architects——The Agentic Enterprise",[60,1673,1675],{"id":1674},"_35-从这些实践得到的启示","3.5 从这些实践得到的启示",[10,1677,1678],{},"综合这些官方资料，可以看到几个共同方向。",[10,1680,1681],{},[19,1682,1683],{},"第一，模型与企业控制能力正在分层。",[10,1685,1686],{},"模型提供理解、推理与规划能力；企业系统提供身份、权限、业务数据、操作接口和治理机制。",[10,1688,1689],{},[19,1690,1691],{},"第二，Agent 不应绕过已有业务系统。",[10,1693,1694],{},"业务规则、交易约束和最终数据一致性仍应由确定性的业务服务保障。",[10,1696,1697],{},[19,1698,1699],{},"第三，Agent 的运行状态、记忆和权限需要独立治理。",[10,1701,1702],{},"一次对话的上下文，并不足以代表完整的企业任务状态。",[10,1704,1705],{},[19,1706,1707],{},"第四，Agent 不应该只能被动响应。",[10,1709,1710],{},"对于研发协作、运维、客服和业务流程等场景，Agent 可以通过事件订阅、任务调度和状态管理主动参与工作。",[10,1712,1713],{},"但这种主动性必须受到明确的权限、触发条件和执行边界约束。",[10,1715,1716],{},"当然，厂商官方架构描述的是其产品设计方向，不能直接等同于所有客户的实际生产效果。具体收益仍需要通过真实业务指标验证。",[55,1718,1720],{"id":1719},"四企业级-agent-的七个核心技术挑战","四、企业级 Agent 的七个核心技术挑战",[10,1722,1723],{},"基于上述需求和研发协作场景，可以将企业 Agent 的关键工程问题归纳为七个方面。",[60,1725,1727],{"id":1726},"_41-主动感知从被动对话到事件驱动","4.1 主动感知：从被动对话到事件驱动",[10,1729,1730],{},"传统 Chatbot 通常由用户主动发起请求。",[10,1732,1733],{},"但在企业研发协作中，很多任务是由业务事件触发的。",[10,1735,126],{},[92,1737,1738,1741,1744,1747,1750],{},[95,1739,1740],{},"云效新增或更新 Bug。",[95,1742,1743],{},"飞书测试群出现新的问题反馈。",[95,1745,1746],{},"PR 审核状态发生变化。",[95,1748,1749],{},"CI 执行失败。",[95,1751,1752],{},"测试人员反馈问题仍然存在。",[10,1754,1755],{},"系统需要持续感知这些事件，并判断是否应该创建任务、更新已有任务或通知相关人员。",[10,1757,1758],{},"这里首先涉及传统事件驱动架构中的问题：",[92,1760,1761,1764,1767,1770,1773,1776],{},[95,1762,1763],{},"Webhook 与 Polling 如何选择？",[95,1765,1766],{},"重复事件如何去重？",[95,1768,1769],{},"乱序事件如何处理？",[95,1771,1772],{},"外部系统不可用时如何补偿？",[95,1774,1775],{},"多个事件如何关联到同一个 Bug？",[95,1777,1778],{},"如何避免反复触发相同的 Agent 任务？",[10,1780,1781],{},"一个重要的设计原则是：",[10,1783,1784],{},[19,1785,1786],{},"事件接入、去重、状态管理等确定性工作，应优先由传统程序完成；需要语义理解和不确定性判断的环节，再交给模型。",[10,1788,1789],{},"例如，飞书消息是否属于 Bug 反馈，可以使用模型分类；但事件 ID 去重不需要 LLM。",[10,1791,1792],{},"此外，群聊消息可能包含敏感信息、个人讨论或与研发无关的内容，因此必须明确采集范围、访问授权、保留策略和数据最小化原则。",[60,1794,1796],{"id":1795},"_42-多用户多角色与权限边界","4.2 多用户、多角色与权限边界",[10,1798,1799],{},"企业中存在不同的组织、部门、岗位和审批职责。",[10,1801,1802],{},"同一个 Agent 面对不同用户时，能够访问的数据和执行的操作可能完全不同。",[10,1804,126],{},[92,1806,1807,1810,1813,1816],{},[95,1808,1809],{},"测试人员可以提交 Bug、查询测试任务。",[95,1811,1812],{},"研发人员可以查看授权范围内的代码仓库和任务。",[95,1814,1815],{},"技术负责人可以管理项目任务、审核代码变更。",[95,1817,1818],{},"CI 服务身份可以执行限定范围的自动化测试。",[10,1820,1821],{},"这里至少存在两类角色：",[10,1823,1824,1827],{},[19,1825,1826],{},"用户角色（User Role）","：决定用户在组织中的业务权限。",[10,1829,1830,1833],{},[19,1831,1832],{},"Agent 角色（Agent Role）","：决定 Agent 承担什么任务、具备什么专业能力。",[10,1835,1836],{},"二者必须分开。",[10,1838,1839],{},"一个负责代码修复的 Agent，不应该天然拥有全部代码仓库的修改权限；一个 Supervisor Agent 将任务交给其他 Agent，也不应该自动扩大原始任务的授权范围。",[10,1841,1842],{},"对于主动触发的任务，还需要明确自动化服务身份、任务授权来源以及允许执行的操作范围。",[10,1844,1845],{},"因此，企业 Agent 的权限检查必须覆盖数据采集、知识检索、上下文构建、工具执行和任务恢复等环节。",[60,1847,1849],{"id":1848},"_43-多层记忆与组织知识共享","4.3 多层记忆与组织知识共享",[10,1851,1852],{},"Agent Memory 不应该简单理解为“将聊天记录保存到向量数据库”。",[10,1854,1855],{},"企业中的信息具有不同来源、作用域、可信度和生命周期。",[10,1857,1858],{},"从内容角度，可以研究：",[92,1860,1861,1867,1873],{},[95,1862,1863,1866],{},[19,1864,1865],{},"Semantic Memory","：业务事实、项目知识和技术约定。",[95,1868,1869,1872],{},[19,1870,1871],{},"Episodic Memory","：历史 Bug、任务执行经历和修复结果。",[95,1874,1875,1878],{},[19,1876,1877],{},"Procedural Memory","：可复用的排查方法、操作流程和修复经验。",[10,1880,1881],{},"从访问范围角度，可以划分：",[92,1883,1884,1887,1890,1893,1896],{},[95,1885,1886],{},"个人私有记忆。",[95,1888,1889],{},"Agent 工作记忆。",[95,1891,1892],{},"项目共享记忆。",[95,1894,1895],{},"团队共享记忆。",[95,1897,1898],{},"组织级共享记忆。",[10,1900,1901],{},"这两个维度相互独立。",[10,1903,1904],{},"例如，一次退款接口异常的修复记录属于 Episodic Memory，但它可能只允许订单研发团队访问。",[10,1906,1907],{},"企业记忆还需要处理更复杂的问题。",[10,1909,1910],{},[19,1911,1912],{},"记忆如何形成？",[10,1914,1915],{},"Coding Agent 推测某段代码存在并发问题，是否可以直接保存为长期事实？还是需要通过测试和人工审核后才能确认？",[10,1917,1918],{},[19,1919,1920],{},"记忆如何共享？",[10,1922,1923],{},"某个开发人员的排查经验什么时候可以升级为团队知识？共享时是否需要删除客户数据、密钥或内部敏感信息？",[10,1925,1926],{},[19,1927,1928],{},"记忆如何更新？",[10,1930,1931],{},"当新的修复结论推翻旧结论时，是覆盖、保留版本，还是标记旧结论已失效？",[10,1933,1934],{},[19,1935,1936],{},"记忆如何撤回？",[10,1938,1939],{},"当用户删除信息或组织权限发生变化时，原始数据、向量索引、摘要和缓存如何同步失效？",[10,1941,1942,1943,1271],{},"还需要区分",[19,1944,1945],{},"权威业务数据与 Agent 记忆",[10,1947,1948],{},"例如，代码模块负责人应该优先从明确维护的 CODEOWNERS、项目配置或任务系统中获取，而不是仅凭历史聊天记录猜测。",[10,1950,1951],{},"这些问题决定了企业记忆系统能否被信任。",[60,1953,1955],{"id":1954},"_44-多-agent-协作与任务编排","4.4 多 Agent 协作与任务编排",[10,1957,1958],{},"研发协作涉及多个不同的专业环节。",[10,1960,1961],{},"例如，一个 Bug 的处理可能需要：",[1026,1963,1964,1970,1976,1982],{},[95,1965,1966,1969],{},[19,1967,1968],{},"Triage Agent","：识别、归类和关联缺陷。",[95,1971,1972,1975],{},[19,1973,1974],{},"Diagnosis Agent","：分析代码、日志和历史问题。",[95,1977,1978,1981],{},[19,1979,1980],{},"Coding Agent","：修改代码、运行测试。",[95,1983,1984,1987],{},[19,1985,1986],{},"Coordinator","：管理任务状态、通知负责人并跟踪反馈。",[10,1989,1990],{},"但需要警惕一个误区：",[10,1992,1993],{},[19,1994,1995],{},"业务存在多个角色，不代表技术上必须使用多个 LLM Agent。",[10,1997,1998],{},"例如，负责人查询可以由确定性服务完成；任务状态更新可以由 Workflow 负责；只有复杂的代码分析与修复才可能需要专门的 Coding Agent。",[10,2000,2001],{},"因此，多 Agent 架构应该回答：",[92,2003,2004,2007,2010,2013,2016],{},[95,2005,2006],{},"为什么单 Agent 无法满足需求？",[95,2008,2009],{},"Agent 之间传递什么状态？",[95,2011,2012],{},"如何避免重复工作和循环委派？",[95,2014,2015],{},"任务交接时如何保持用户授权？",[95,2017,2018],{},"如何判断协作带来的收益超过额外成本？",[10,2020,2021],{},"我们不应该为了展示 Multi-Agent 技术而强行拆分多个 Agent。",[60,2023,2025],{"id":2024},"_45-coding-agent代码执行与安全边界","4.5 Coding Agent：代码执行与安全边界",[10,2027,2028],{},"在开发人员工作台中，使用 Coding Agent 辅助实现需求或修复 Bug，是最有价值、也最需要谨慎设计的能力之一。",[10,2030,2031],{},"Coding Agent 可能需要：",[92,2033,2034,2037,2040,2043,2046,2049,2052],{},[95,2035,2036],{},"读取代码仓库。",[95,2038,2039],{},"搜索相关文件和调用链。",[95,2041,2042],{},"修改代码。",[95,2044,2045],{},"安装依赖。",[95,2047,2048],{},"执行测试。",[95,2050,2051],{},"提交 Git Commit。",[95,2053,2054],{},"创建 Draft PR。",[10,2056,2057],{},"这些操作涉及真实的代码执行和外部副作用，因此需要考虑：",[10,2059,2060],{},[19,2061,2062],{},"仓库与分支权限。",[10,2064,2065],{},"Agent 只能访问授权仓库，默认不直接修改受保护分支。",[10,2067,2068],{},[19,2069,2070],{},"命令与网络权限。",[10,2072,2073],{},"不能将模型生成的任意 Shell 命令视为可信输入；需要对执行能力、网络访问和敏感凭据进行约束。",[10,2075,2076],{},[19,2077,2078],{},"代码质量验证。",[10,2080,2081],{},"单元测试通过并不意味着 Bug 已修复。还需要结合回归测试、代码审查和原始问题的复现条件。",[10,2083,2084],{},[19,2085,2086],{},"人工审核。",[10,2088,2089],{},"第一阶段可以允许 Agent 在限定条件下创建 Draft PR，但不自动合并或部署生产环境。",[10,2091,2092],{},"这也带来一个重要的评估问题：",[10,2094,2095],{},[19,2096,2097],{},"成功创建 PR，不等于成功修复 Bug。",[60,2099,2101],{"id":2100},"_46-长期任务与可靠执行","4.6 长期任务与可靠执行",[10,2103,2104],{},"从 Bug 发现到最终解决，可能持续数小时甚至数天。",[10,2106,126],{},[92,2108,2109,2112,2115,2118,2121],{},[95,2110,2111],{},"周一：测试人员反馈 Bug。",[95,2113,2114],{},"周二：Agent 完成分析并创建 Draft PR。",[95,2116,2117],{},"周三：开发人员审核，提出修改意见。",[95,2119,2120],{},"周四：Agent 根据反馈更新补丁。",[95,2122,2123],{},"周五：CI 通过，测试人员完成验证。",[10,2125,2126],{},"这是一个长期存在的任务，而不是一次 LLM 请求。",[10,2128,2129],{},"系统需要支持：",[92,2131,2132,2135,2138,2141,2144,2147,2150],{},[95,2133,2134],{},"任务状态持久化。",[95,2136,2137],{},"等待外部事件。",[95,2139,2140],{},"任务暂停、恢复和取消。",[95,2142,2143],{},"工具执行超时。",[95,2145,2146],{},"重复事件处理。",[95,2148,2149],{},"重启后的任务恢复。",[95,2151,2152],{},"外部副作用的结果核验。",[10,2154,2155],{},"例如，Agent 调用 Git 平台创建 PR：",[1026,2157,2158,2161,2164],{},[95,2159,2160],{},"PR 已成功创建。",[95,2162,2163],{},"网络连接发生超时。",[95,2165,2166],{},"Agent 没有收到成功响应。",[10,2168,2169],{},"此时直接重试，可能创建重复 PR。",[10,2171,2172],{},"因此，需要通过幂等标识、关联查询或人工核查确认外部操作结果。",[10,2174,2175],{},[19,2176,2177],{},"任务状态恢复，不等于外部业务副作用可以安全重放。",[10,2179,2180],{},"这也是企业 Agent Runtime 与传统分布式系统可靠性设计的重要交汇点。",[60,2182,2184],{"id":2183},"_47-可观测性评估与成本控制","4.7 可观测性、评估与成本控制",[10,2186,2187],{},"传统系统可以通过错误率、吞吐量、延迟和资源利用率等指标判断运行状态。",[10,2189,2190],{},"Agent 还需要回答：",[10,2192,2193],{},[19,2194,2195],{},"系统运行成功，是否意味着任务完成正确？",[10,2197,2198],{},"例如，一个 Agent 成功读取代码、生成补丁、运行测试并创建 PR，但它修改了错误的模块，或者仅仅绕过了失败的测试。",[10,2200,2201],{},"从工具执行角度看，所有调用可能都成功了；从业务角度看，任务仍然失败。",[10,2203,2204],{},"因此，企业 Agent 需要同时建立：",[10,2206,2207,2210],{},[19,2208,2209],{},"技术指标","：延迟、Token 消耗、工具失败率、资源利用率、任务恢复情况。",[10,2212,2213,2216],{},[19,2214,2215],{},"行为指标","：Bug 识别准确率、工具选择正确率、任务步骤合理性、记忆召回质量、权限违规次数。",[10,2218,2219,2222],{},[19,2220,2221],{},"业务指标","：有效 Bug 发现率、重复任务率、修复成功率、PR 审核通过率、人工接管率、平均处理时间和单位任务成本。",[10,2224,2225],{},"评估不应该等到项目开发完成后才补充，而应该从最小可运行版本开始建立。",[55,2227,2229],{"id":2228},"五建设企业-agent应该采购定制还是自研","五、建设企业 Agent：应该采购、定制还是自研？",[10,2231,2232],{},"讨论企业为什么需要自己的 Agent，还必须回答一个现实问题：企业是否真的应该自己开发？",[10,2234,2235],{},"答案并不总是肯定的。",[403,2237,2238,2248],{},[406,2239,2240],{},[409,2241,2242,2245],{},[412,2243,2244],{},"业务场景",[412,2246,2247],{},"建议优先考虑",[419,2249,2250,2258,2266,2274,2282,2290],{},[409,2251,2252,2255],{},[424,2253,2254],{},"通用文档处理、会议总结",[424,2256,2257],{},"成熟通用 AI 产品",[409,2259,2260,2263],{},[424,2261,2262],{},"企业知识问答",[424,2264,2265],{},"现有 Agent 平台与知识库方案",[409,2267,2268,2271],{},[424,2269,2270],{},"单部门流程自动化",[424,2272,2273],{},"成熟工作流或 Agent 框架",[409,2275,2276,2279],{},[424,2277,2278],{},"代码生成和单次修复任务",[424,2280,2281],{},"成熟 Coding Agent",[409,2283,2284,2287],{},[424,2285,2286],{},"跨系统研发协作与持续任务跟踪",[424,2288,2289],{},"专属 Agent 应用与控制能力",[409,2291,2292,2295],{},[424,2293,2294],{},"多团队共建 Agent 平台",[424,2296,2297],{},"统一治理与共享基础设施",[10,2299,2300],{},"即使决定自研，也不意味着所有组件都应该自行实现。",[10,2302,2303],{},"模型推理、Embedding、向量检索、工作流框架、MCP 协议、可观测性基础设施，以及 Coding Agent 本身，都可以优先考虑成熟方案。",[10,2305,2306],{},"更合理的建设原则是：",[29,2308,2309],{},[10,2310,2311],{},"对通用能力优先复用，对企业差异化能力重点建设，对关键架构决策进行验证。",[10,2313,2314],{},"这里还需要考虑长期总拥有成本，包括研发投入、部署维护、模型调用、合规成本、故障处理和后续升级。",[10,2316,2317],{},"自研带来的灵活性，必须能够覆盖它增加的复杂度。",[55,2319,2321],{"id":2320},"六项目定位面向研发全流程的智能开发人员工作台","六、项目定位：面向研发全流程的智能开发人员工作台",[10,2323,2324],{},"基于前面的研究，近期实践方向可以定义为：",[10,2326,2327],{},[19,2328,2329],{},"一个以研发任务为中心，覆盖技术方案、开发、自测、Code Review、提测、测试反馈和上线准备等环节的智能开发人员工作台。",[10,2331,2332],{},"它通过可治理、可恢复、可验证的 Agent 能力持续参与研发流程，并以测试阶段的 Bug 处理作为第一个主动式闭环。",[10,2334,2335],{},"项目的目标层次是：",[68,2337,2340],{"className":2338,"code":2339,"language":73,"meta":74},[71],"长期愿景：企业级数字员工\n               ↑\n演进方向：主动式研发协作 Agent\n               ↑\n产品形态：智能开发人员工作台\n               ↑\n首个闭环：测试阶段 Bug 的发现、修复与回归跟踪\n",[76,2341,2339],{"__ignoreMap":74},[10,2343,2344],{},"开发人员工作台不是另一个 IDE，也不是另一个聊天机器人。它位于需求管理、协作工具、代码仓库、Coding Agent、CI 和测试环境之上，以研发任务为主线组织上下文、产物、执行状态和验收证据。",[60,2346,2348],{"id":2347},"_61-核心领域对象","6.1 核心领域对象",[10,2350,2351],{},"系统首先需要理解的不是“有多少个 Agent”，而是一个研发任务包含哪些持续演进的信息。",[68,2353,2356],{"className":2354,"code":2355,"language":73,"meta":74},[71],"研发任务 WorkItem\n├── 原始需求与验收标准\n├── 项目、模块与负责人\n├── 技术方案与接口文档\n├── 开发计划\n├── 代码分支、Commit 与 PR\u002FMR\n├── 自测、CI 与测试环境结果\n├── Code Review 意见\n├── 云效 Bug 与飞书测试反馈\n├── 修复记录\n└── 发布及最终验证证据\n",[76,2357,2355],{"__ignoreMap":74},[10,2359,2360],{},"围绕 WorkItem，可以进一步抽象：",[92,2362,2363,2369,2375,2381,2387,2393],{},[95,2364,2365,2368],{},[19,2366,2367],{},"Context","：需求、代码、文档、规范、日志和历史记录。",[95,2370,2371,2374],{},[19,2372,2373],{},"Artifact","：技术方案、接口文档、代码、PR\u002FMR 和测试报告。",[95,2376,2377,2380],{},[19,2378,2379],{},"Run","：某次 Workflow、Agent 或工具执行。",[95,2382,2383,2386],{},[19,2384,2385],{},"Evidence","：编译、测试、CI、Review 和回归验证结果。",[95,2388,2389,2392],{},[19,2390,2391],{},"Approval","：需要开发人员、负责人或测试人员确认的关键节点。",[95,2394,2395,2398],{},[19,2396,2397],{},"Memory","：经过验证、具有来源和作用域的可复用经验。",[60,2400,2402],{"id":2401},"_62-三个核心研究问题","6.2 三个核心研究问题",[10,2404,2405],{},[19,2406,2407],{},"问题一：如何以研发任务为中心，持续组织需求、文档、代码、测试和反馈？",[10,2409,2410],{},"研究任务生命周期、上下文装配、产物关联、证据记录以及需求、Bug、分支、Commit、PR\u002FMR 和 CI 之间的可追溯关系。",[10,2412,2413],{},[19,2414,2415],{},"问题二：如何组合确定性 Workflow、模型判断和 Coding Agent？",[10,2417,2418],{},"研究哪些环节应由程序和状态机执行，哪些环节需要模型理解，哪些代码任务可以委托给成熟 Coding Agent，以及在哪里保留人工检查点。",[10,2420,2421],{},[19,2422,2423],{},"问题三：如何让长期研发任务可恢复、可授权、可追踪并以证据验收？",[10,2425,2426],{},"研究状态持久化、工具调用、审批、幂等、外部事件等待、结果核验、失败恢复和审计。",[10,2428,2429],{},"多 Agent、共享记忆和通用 Agent Runtime 是这些问题的候选解决手段，而不是预设目标。",[60,2431,2433],{"id":2432},"_63-初步逻辑架构","6.3 初步逻辑架构",[68,2435,2438],{"className":2436,"code":2437,"language":73,"meta":74},[71],"┌────────────────────────────────────────────┐\n│  需求 \u002F 文档 \u002F 云效 \u002F 飞书 \u002F Git \u002F CI \u002F 测试环境  │\n└─────────────────────┬──────────────────────┘\n                      │\n┌─────────────────────▼──────────────────────┐\n│       Integration & Event Ingestion        │\n│ Adapter \u002F Webhook \u002F Polling \u002F 去重 \u002F 关联 \u002F 授权 │\n└─────────────────────┬──────────────────────┘\n                      │\n┌─────────────────────▼──────────────────────┐\n│         Development Workbench Core         │\n│ WorkItem \u002F Lifecycle \u002F Artifact \u002F Evidence │\n│ Approval \u002F Timeline \u002F Project Context      │\n└──────────────┬─────────────────┬───────────┘\n               │                 │\n┌──────────────▼───────┐ ┌───────▼──────────┐\n│ Workflow Orchestration│ │  Agent Execution │\n│ 状态 \u002F 等待 \u002F 恢复 \u002F 补偿 │ │ LLM \u002F Coding Agent│\n└──────────────┬───────┘ └───────┬──────────┘\n               │                 │\n┌──────────────▼─────────────────▼───────────┐\n│ Identity \u002F Policy \u002F Audit \u002F Memory \u002F Eval  │\n└────────────────────────────────────────────┘\n",[76,2439,2437],{"__ignoreMap":74},[10,2441,2442],{},"这只是逻辑能力划分，不代表最终必须采用微服务架构，也不代表每个模块都需要独立部署。",[10,2444,2445],{},"云效、飞书、Git 平台、CI 和 Coding Agent 应通过适配器接入。核心 WorkItem、状态流转、权限判断和验收规则不能依赖某个 Agent 框架，也不应交给模型自行决定。",[60,2447,2449],{"id":2448},"_64-关键架构设计目标","6.4 关键架构设计目标",[403,2451,2452,2462],{},[406,2453,2454],{},[409,2455,2456,2459],{},[412,2457,2458],{},"设计目标",[412,2460,2461],{},"初步要求",[419,2463,2464,2472,2480,2488,2496,2504,2512,2520,2528,2536],{},[409,2465,2466,2469],{},[424,2467,2468],{},"任务可追溯",[424,2470,2471],{},"需求、文档、代码、Bug、PR\u002FMR、CI 和测试结果可以相互关联",[409,2473,2474,2477],{},[424,2475,2476],{},"证据可验证",[424,2478,2479],{},"完成状态必须具有编译、测试、Review 或回归验证证据",[409,2481,2482,2485],{},[424,2483,2484],{},"事件可追溯",[424,2486,2487],{},"保留来源、事件标识和处理状态",[409,2489,2490,2493],{},[424,2491,2492],{},"模型可替换",[424,2494,2495],{},"不与单一模型供应商强绑定",[409,2497,2498,2501],{},[424,2499,2500],{},"执行器可替换",[424,2502,2503],{},"支持替换 Coding Agent 与 Workflow 实现",[409,2505,2506,2509],{},[424,2507,2508],{},"权限可验证",[424,2510,2511],{},"数据访问与工具执行具有程序级授权检查",[409,2513,2514,2517],{},[424,2515,2516],{},"记忆可治理",[424,2518,2519],{},"支持来源、作用域、验证、更新、撤回和审计",[409,2521,2522,2525],{},[424,2523,2524],{},"任务可恢复",[424,2526,2527],{},"支持持久状态、外部事件等待及不确定副作用处理",[409,2529,2530,2533],{},[424,2531,2532],{},"行为可追踪",[424,2534,2535],{},"能追踪任务、模型调用、工具执行和人工操作",[409,2537,2538,2541],{},[424,2539,2540],{},"质量可评估",[424,2542,2543],{},"建立固定任务集与自动化回归",[10,2545,2546],{},"这些目标还不是已实现功能，而是后续设计、技术选型和验收的依据。",[55,2548,2550],{"id":2549},"七mvp从研发任务工作台到主动式-bug-闭环","七、MVP：从研发任务工作台到主动式 Bug 闭环",[10,2552,2553],{},"第一阶段不建设完整的企业数字员工平台，而是先建立研发任务的领域骨架，再逐步加入 Agent 能力。",[60,2555,2557],{"id":2556},"_71-v0研发任务工作台骨架","7.1 V0：研发任务工作台骨架",[10,2559,2560],{},"即使暂时没有 Agent，系统也应该能够正确表达研发流程：",[92,2562,2563,2566,2569,2572,2575],{},[95,2564,2565],{},"建立 Project、WorkItem、Artifact、Evidence、Approval 和 Run 等核心对象。",[95,2567,2568],{},"表达需求、开发、自测、Code Review、提测、测试、上线准备和发布等状态。",[95,2570,2571],{},"表达测试阶段 Bug 的创建、修复、标记已修复、回归、关闭与重新打开。",[95,2573,2574],{},"记录任务时间线和每次状态变化的操作者、来源与证据。",[95,2576,2577],{},"使用模拟适配器接入云效、飞书、Git 和 CI 数据。",[10,2579,2580],{},"这一阶段重点验证领域模型，而不是 Agent 的智能程度。",[60,2582,2584],{"id":2583},"_72-v1从任务到可验证的-draft-prmr","7.2 V1：从任务到可验证的 Draft PR\u002FMR",[10,2586,2587],{},"在工作台骨架上增加受控的开发能力：",[92,2589,2590,2593,2596,2599,2602,2605,2608],{},[95,2591,2592],{},"手工创建或导入一个需求、开发任务或 Bug。",[95,2594,2595],{},"关联项目规范、代码仓库、技术文档和验收要求。",[95,2597,2598],{},"生成技术方案或开发计划草稿，并由开发人员确认。",[95,2600,2601],{},"接入成熟 Coding Agent，在隔离工作区和授权分支中修改代码。",[95,2603,2604],{},"运行编译、单元测试和必要的静态检查。",[95,2606,2607],{},"展示 Diff、测试结果、未验证项和剩余风险。",[95,2609,2610],{},"经人工确认后创建 Draft PR\u002FMR，并保存执行证据。",[10,2612,2613],{},"这一阶段重点验证上下文装配、Coding Agent 适配、工作区安全和证据驱动的完成标准。",[60,2615,2617],{"id":2616},"_73-v2测试阶段-bug-主动处理闭环","7.3 V2：测试阶段 Bug 主动处理闭环",[10,2619,2620],{},"在 V1 的基础上增加主动事件和长期跟踪：",[92,2622,2623,2626,2629,2632,2635,2638,2641],{},[95,2624,2625],{},"接收云效 Bug 和飞书测试反馈。",[95,2627,2628],{},"对重复事件进行幂等处理，并关联同一问题的多种来源。",[95,2630,2631],{},"关联原始需求、负责人、代码分支、Commit、PR\u002FMR 和测试环境。",[95,2633,2634],{},"在授权范围内启动问题分析、代码修复、自测和 Draft PR\u002FMR。",[95,2636,2637],{},"跟踪必要的增量 Code Review、CI 和测试环境部署。",[95,2639,2640],{},"满足预设条件后，将 Bug 标记为“已修复”，等待测试人员回归。",[95,2642,2643],{},"回归失败时重新打开并恢复原任务；验证通过后关闭 Bug。",[10,2645,2646],{},"这一阶段重点验证主动触发、外部事件等待、任务恢复、状态一致性和完整研发闭环。",[60,2648,2650],{"id":2649},"_74-v3治理记忆与可评估协作","7.4 V3：治理、记忆与可评估协作",[10,2652,2653],{},"进一步支持：",[92,2655,2656,2659,2662,2665,2668,2671],{},[95,2657,2658],{},"用户身份、服务身份和委托权限。",[95,2660,2661],{},"工具审批、命令与仓库访问边界。",[95,2663,2664],{},"任务超时、取消、重试、补偿和不确定副作用核验。",[95,2666,2667],{},"将经过测试回归或合并验证的修复经验晋升为候选团队记忆。",[95,2669,2670],{},"使用固定案例评估不同模型、Workflow 和 Coding Agent。",[95,2672,2673],{},"只有在单 Agent 或 Workflow 无法满足需求时，再引入多 Agent 协作。",[60,2675,2677],{"id":2676},"_75-mvp-的验收标准","7.5 MVP 的验收标准",[10,2679,2680],{},"为了避免项目变成只有演示效果的 Demo，需要设计可重复的测试。",[403,2682,2683,2693],{},[406,2684,2685],{},[409,2686,2687,2690],{},[412,2688,2689],{},"验收场景",[412,2691,2692],{},"预期结果",[419,2694,2695,2703,2711,2719,2727,2735,2743,2751,2759,2767,2775,2783],{},[409,2696,2697,2700],{},[424,2698,2699],{},"一个研发任务跨越多个阶段",[424,2701,2702],{},"文档、代码、测试和状态仍关联到同一 WorkItem",[409,2704,2705,2708],{},[424,2706,2707],{},"飞书重复推送相同消息",[424,2709,2710],{},"不重复创建任务",[409,2712,2713,2716],{},[424,2714,2715],{},"云效与飞书反馈同一问题",[424,2717,2718],{},"能识别关联关系并保留不同来源",[409,2720,2721,2724],{},[424,2722,2723],{},"用户无权访问目标仓库",[424,2725,2726],{},"不向 Coding Agent 暴露仓库内容",[409,2728,2729,2732],{},[424,2730,2731],{},"历史修复记录与当前证据冲突",[424,2733,2734],{},"保留来源并标记不确定性",[409,2736,2737,2740],{},[424,2738,2739],{},"PR\u002FMR 创建成功但响应超时",[424,2741,2742],{},"查询外部状态，不盲目重复创建",[409,2744,2745,2748],{},[424,2746,2747],{},"任务执行中进程重启",[424,2749,2750],{},"能从持久状态和已有证据继续",[409,2752,2753,2756],{},[424,2754,2755],{},"Coding Agent 修改错误模块",[424,2757,2758],{},"通过测试、Review 或评测识别问题",[409,2760,2761,2764],{},[424,2762,2763],{},"未部署到测试环境或必要检查未通过",[424,2765,2766],{},"不自动将 Bug 标记为已修复",[409,2768,2769,2772],{},[424,2770,2771],{},"测试回归失败",[424,2773,2774],{},"重新打开 Bug，并恢复原修复任务",[409,2776,2777,2780],{},[424,2778,2779],{},"修复经验尚未验证",[424,2781,2782],{},"不直接晋升为团队长期记忆",[409,2784,2785,2788],{},[424,2786,2787],{},"相同案例重复评测",[424,2789,2790],{},"可以比较不同版本的质量、时间和成本",[10,2792,2793],{},"初期可以通过示例代码仓库、预置需求与 Bug、模拟飞书消息、云效数据和 CI 事件构建可复现环境，不依赖真实企业生产系统。",[10,2795,2796],{},"具体指标和阈值应在实现及基准测试后确定，不提前宣称生产级可靠性。",[55,2798,2800],{"id":2799},"八第一阶段明确不做什么","八、第一阶段明确不做什么",[10,2802,2803],{},"项目最容易遇到的问题之一，就是不断扩展功能范围。",[10,2805,2806],{},"因此，需要明确 V1 的非目标。",[10,2808,2809,2812],{},[19,2810,2811],{},"不自研基础大模型。"," 优先复用现有模型和推理服务。",[10,2814,2815,2818],{},[19,2816,2817],{},"不预设必须自研 Agent Runtime。"," 先研究成熟框架，再根据需求决定是否需要扩展或替换。",[10,2820,2821,2824],{},[19,2822,2823],{},"不从零开发完整 Coding Agent。"," 优先研究现有代码智能体的集成方式。",[10,2826,2827,2830],{},[19,2828,2829],{},"不追求无限自主执行。"," 主动执行必须受到明确约束。",[10,2832,2833,2836],{},[19,2834,2835],{},"不强制所有业务使用 Multi-Agent。"," 简单任务优先使用简单方案。",[10,2838,2839,2842],{},[19,2840,2841],{},"不建设完整企业 SaaS 或通用数字员工平台。"," 第一阶段重点验证研发任务、受控执行、证据和主动式 Bug 闭环。",[10,2844,2845,2848],{},[19,2846,2847],{},"不自动合并 PR 或部署生产环境。"," 初期只创建 Draft PR，并保留人工审核。",[10,2850,2851,2854],{},[19,2852,2853],{},"不把架构设计当作已验证成果。"," 所有关键结论都应有实现、测试或公开证据支持。",[55,2856,2858],{"id":2857},"九开发与写作让技术研究成为项目的一部分","九、开发与写作：让技术研究成为项目的一部分",[10,2860,2861],{},"这个项目还有一个重要目标：通过公开技术研究，建立系统性的 Agent 工程知识体系。",[10,2863,2864],{},"开发过程与技术文章可以结合，但不应把文章写成简单的开发日志。",[10,2866,2867],{},"每个重要技术专题尽量遵循相同的过程。",[10,2869,2870],{},[19,2871,2872],{},"第一步：研究问题。",[10,2874,2875],{},"理解业务需求、技术背景和已有解决方案。",[10,2877,2878],{},[19,2879,2880],{},"第二步：比较方案。",[10,2882,2883],{},"研究主流框架、官方文档、开源源码、社区 Issue 及不同架构的适用条件。",[10,2885,2886],{},[19,2887,2888],{},"第三步：验证假设。",[10,2890,2891],{},"对于关键技术取舍，使用最小实现、测试或 Benchmark 验证。",[10,2893,2894],{},[19,2895,2896],{},"第四步：记录决策。",[10,2898,2899],{},"通过 ADR 说明选择理由、放弃的方案、已知限制和未来重新评估的条件。",[10,2901,2902],{},[19,2903,2904],{},"第五步：开源实现。",[10,2906,2907],{},"公开可运行代码、测试、示例和必要的技术文档。",[10,2909,2910],{},[19,2911,2912],{},"第六步：总结反馈。",[10,2914,2915],{},"根据测试、实际使用和社区反馈，持续修正设计。",[10,2917,2918],{},"这意味着技术文章和开源代码会相互支撑：",[92,2920,2921,2924,2927,2930,2933],{},[95,2922,2923],{},"技术文章解释为什么这样设计。",[95,2925,2926],{},"开源代码展示实际如何实现。",[95,2928,2929],{},"自动化测试验证设计是否成立。",[95,2931,2932],{},"社区反馈帮助发现认知盲区。",[95,2934,2935],{},"后续文章记录方案如何演进。",[55,2937,2939],{"id":2938},"十总结企业-agent-的价值不只是更聪明","十、总结：企业 Agent 的价值不只是更聪明",[10,2941,2942],{},"回到最初的问题：",[10,2944,2945],{},[19,2946,2947],{},"通用 Agent 已经很强，企业为什么还需要自己的 Agent？",[10,2949,2950],{},"答案不是因为通用模型不够聪明，而是因为企业软件的价值不仅来自智能，还来自业务上下文、组织权限、数据治理、可靠执行和可验证的结果。",[10,2952,2953],{},"通用模型能够帮助系统理解“应该做什么”。",[10,2955,2956],{},"但企业仍然需要回答：",[92,2958,2959,2962,2965,2968,2971,2974,2977,2980,2983],{},[95,2960,2961],{},"什么事件应该触发 Agent？",[95,2963,2964],{},"谁允许它执行？",[95,2966,2967],{},"它可以使用哪些数据？",[95,2969,2970],{},"它应该调用哪个业务系统？",[95,2972,2973],{},"多个 Agent 如何共享任务上下文？",[95,2975,2976],{},"外部操作成功与否如何判断？",[95,2978,2979],{},"失败后如何安全恢复？",[95,2981,2982],{},"哪些信息可以长期保存和共享？",[95,2984,306],{},[10,2986,2987],{},"这些问题共同构成了企业级 Agent 工程的核心。",[10,2989,2990],{},"未来，随着通用模型和 Agent 平台继续发展，企业自研的边界也会变化。今天需要自己实现的基础能力，明天可能成为成熟平台的一部分。",[10,2992,2993],{},"因此，真正重要的不是坚持自研某个框架，而是理解问题、识别边界，并做出合理的技术选择。",[10,2995,2996],{},"本系列将以智能开发人员工作台为近期实践载体，从研发任务模型出发，逐步研究上下文工程、Workflow 与 Agent 的边界、Coding Agent 集成、测试阶段 Bug 闭环、长期任务、权限治理、可观测性、评估和团队记忆，并最终探索企业级数字员工的演进路径。",[10,2998,2999],{},[19,3000,3001],{},"我们的目标不是重新发明一个通用 Agent，而是探索如何让 Agent 成为企业研发体系中可信、可控、可维护的协作参与者。",[55,3003,1024],{"id":1024},[10,3005,3006],{},"以下资料主要用于分析企业需求和架构方向。招聘信息具有时效性，厂商官方资料不等同于独立生产效果评测。",[1026,3008,3009,3016,3023,3030,3037,3044,3051,3058,3066,3074],{},[95,3010,3011,3015],{},[1031,3012,3014],{"href":1382,"rel":3013},[1035],"滴滴招聘：AI Agent 基建平台架构师"," — Agent 生命周期、编排、运行时与稳定性要求。",[95,3017,3018,3022],{},[1031,3019,3021],{"href":1392,"rel":3020},[1035],"京东招聘：Agent 平台方向"," — Agent 平台与业务系统集成相关招聘资料。",[95,3024,3025,3029],{},[1031,3026,3028],{"href":1564,"rel":3027},[1035],"Google Cloud：Introducing Gemini Enterprise Agent Platform"," — 企业 Agent 平台能力与治理方向。",[95,3031,3032,3036],{},[1031,3033,3035],{"href":1611,"rel":3034},[1035],"Microsoft：Agent Identity"," — Agent 身份与授权管理。",[95,3038,3039,3043],{},[1031,3040,3042],{"href":1642,"rel":3041},[1035],"AWS：Secure AI Agents with AgentCore Gateway"," — Agent 工具执行的策略与安全控制。",[95,3045,3046,3050],{},[1031,3047,3049],{"href":1669,"rel":3048},[1035],"Salesforce Architects：The Agentic Enterprise"," — 企业 Agent 架构、语义层、编排与治理。",[95,3052,3053,3057],{},[1031,3054,3056],{"href":1066,"rel":3055},[1035],"LangGraph 官方文档"," — 有状态 Agent 工作流与运行时。",[95,3059,3060,3065],{},[1031,3061,3064],{"href":3062,"rel":3063},"https:\u002F\u002Fopenai.github.io\u002Fopenai-agents-python\u002F",[1035],"OpenAI Agents SDK 官方文档"," — Agent、工具、交接与追踪。",[95,3067,3068,3073],{},[1031,3069,3072],{"href":3070,"rel":3071},"https:\u002F\u002Fmodelcontextprotocol.io\u002F",[1035],"Model Context Protocol 官方文档"," — Agent 与外部工具、资源的标准化集成。",[95,3075,3076,3081],{},[1031,3077,3080],{"href":3078,"rel":3079},"https:\u002F\u002Fgenai.owasp.org\u002F",[1035],"OWASP GenAI Security Project"," — 生成式 AI 与 Agent 安全风险。",[3083,3084],"hr",{},[10,3086,3087],{},[13,3088,3089],{},"下一篇：《智能开发人员工作台：产品定位、研发任务模型与系统边界》",[10,3091,3092],{},"下一篇将从研发全流程出发，定义 WorkItem、Context、Artifact、Run、Evidence 与 Approval 等核心对象，分析开发人员、测试人员、Agent 和企业系统的职责边界，并进一步明确第一阶段产品范围。",{"title":74,"searchDepth":1095,"depth":1095,"links":3094},[3095,3099,3102,3109,3118,3119,3125,3132,3133,3134,3135],{"id":1169,"depth":1095,"text":1170,"children":3096},[3097,3098],{"id":1190,"depth":1100,"text":1191},{"id":1277,"depth":1100,"text":1278},{"id":1338,"depth":1095,"text":1339,"children":3100},[3101],{"id":1348,"depth":1100,"text":1349},{"id":1519,"depth":1095,"text":1520,"children":3103},[3104,3105,3106,3107,3108],{"id":1526,"depth":1100,"text":1527},{"id":1569,"depth":1100,"text":1570},{"id":1616,"depth":1100,"text":1617},{"id":1647,"depth":1100,"text":1648},{"id":1674,"depth":1100,"text":1675},{"id":1719,"depth":1095,"text":1720,"children":3110},[3111,3112,3113,3114,3115,3116,3117],{"id":1726,"depth":1100,"text":1727},{"id":1795,"depth":1100,"text":1796},{"id":1848,"depth":1100,"text":1849},{"id":1954,"depth":1100,"text":1955},{"id":2024,"depth":1100,"text":2025},{"id":2100,"depth":1100,"text":2101},{"id":2183,"depth":1100,"text":2184},{"id":2228,"depth":1095,"text":2229},{"id":2320,"depth":1095,"text":2321,"children":3120},[3121,3122,3123,3124],{"id":2347,"depth":1100,"text":2348},{"id":2401,"depth":1100,"text":2402},{"id":2432,"depth":1100,"text":2433},{"id":2448,"depth":1100,"text":2449},{"id":2549,"depth":1095,"text":2550,"children":3126},[3127,3128,3129,3130,3131],{"id":2556,"depth":1100,"text":2557},{"id":2583,"depth":1100,"text":2584},{"id":2616,"depth":1100,"text":2617},{"id":2649,"depth":1100,"text":2650},{"id":2676,"depth":1100,"text":2677},{"id":2799,"depth":1095,"text":2800},{"id":2857,"depth":1095,"text":2858},{"id":2938,"depth":1095,"text":2939},{"id":1024,"depth":1095,"text":1024},"wiki:agent:enterprise-ai-agent-system-requirements-challenges-architecture",{},1,"\u002Fagent\u002Fenterprise-ai-agent-system-requirements-challenges-architecture",{"title":1154,"description":1161},"agent\u002Fenterprise-ai-agent-system-requirements-challenges-architecture","2026-11-09","Y8FDHHpExkmzJje9kXjNXYgjTuhrxsPM7nLhuhWe8Ac",{"id":3145,"title":3146,"body":3147,"commentId":4337,"description":3153,"draft":1141,"extension":1142,"meta":4338,"navigation":1144,"order":1095,"path":4339,"section":1146,"seo":4340,"stem":4341,"updated":4342,"__hash__":4343},"agent\u002Fagent\u002Fdev-workbench-product-positioning-task-model-system-boundary.md","智能开发人员工作台：产品定位、研发任务模型与系统边界",{"type":7,"value":3148,"toc":4291},[3149,3154,3159,3167,3170,3173,3191,3198,3204,3207,3218,3221,3225,3229,3232,3238,3241,3261,3264,3267,3270,3274,3277,3280,3283,3288,3291,3297,3300,3304,3307,3310,3339,3345,3348,3355,3359,3363,3366,3371,3376,3382,3385,3394,3398,3401,3404,3418,3425,3428,3432,3438,3545,3548,3556,3560,3563,3568,3573,3578,3583,3586,3590,3594,3597,3603,3606,3610,3613,3616,3622,3629,3633,3636,3639,3701,3704,3708,3711,3714,3719,3723,3726,3749,3752,3756,3759,3782,3785,3789,3792,3806,3809,3813,3816,3836,3839,3843,3846,3849,3869,3872,3875,3879,3883,3886,3892,3895,3898,3915,3918,3922,3925,3928,3932,3935,3939,3942,3945,3949,3952,3975,3979,3982,3986,3992,3996,3999,4003,4006,4010,4013,4016,4020,4024,4045,4048,4054,4057,4061,4064,4067,4071,4074,4100,4103,4105,4108,4140,4143,4147,4150,4153,4197,4200,4203,4206,4212,4214],[10,3150,3151],{},[13,3152,3153],{},"以 WorkItem 为中心定义研发任务模型，厘清开发数字员工、确定性程序、企业系统与人的职责边界。",[10,3155,3156],{},[19,3157,3158],{},"系列：从零构建企业级 AI Agent · 第 02 篇",[10,3160,3161,3162,3166],{},"上一篇文章《",[1031,3163,1154],{"href":3164,"rel":3165},"https:\u002F\u002Fwww.zhizhi123.com\u002Fwiki\u002Fagent\u002Fenterprise-ai-agent-system-requirements-challenges-architecture\u002F",[1035],"》讨论了企业 Agent 面临的共性问题：业务上下文、组织权限、可靠执行、长期任务、评估和审计。",[10,3168,3169],{},"但如果直接从这些技术问题出发，项目很容易变成一个范围不断扩大的“Agent 平台”：先搭模型网关，再做工具调用，然后加入记忆、Multi-Agent 和工作流引擎，最后却很难说清它究竟在为谁解决什么问题。",[10,3171,3172],{},"因此，这个项目需要一个更具体的近期载体。",[10,3174,3175,3176,3179,3180,3183,3184,3187,3188,1271],{},"我们选择的产品形态是",[19,3177,3178],{},"智能开发人员工作台","；领域边界是",[19,3181,3182],{},"研发全流程","；第一个主动式闭环是",[19,3185,3186],{},"自动处理测试阶段 Bug","；长期方向则是",[19,3189,3190],{},"企业级数字员工",[10,3192,3193,3194,3197],{},"在这个长期方向下，工作台首先要支持的不是一个抽象的“万能 Agent”，而是一个职责明确的角色：",[19,3195,3196],{},"开发数字员工","。它可以像团队中的开发人员一样被加入飞书群，在授权范围内接收群消息和 Bug 反馈，分析问题、设计技术方案、编写和测试代码、提交 Draft PR\u002FMR，并持续汇报任务进展。",[68,3199,3202],{"className":3200,"code":3201,"language":73,"meta":74},[71],"长期愿景：企业级数字员工体系\n               ↑\n首个角色：开发数字员工\n               ↑\n产品与治理底座：智能开发人员工作台\n               ↑\n首个闭环：测试阶段 Bug 的发现、修复与回归跟踪\n",[76,3203,3201],{"__ignoreMap":74},[10,3205,3206],{},"这一定位仍然留下了三个必须回答的问题：",[1026,3208,3209,3212,3215],{},[95,3210,3211],{},"为什么还需要一个开发人员工作台，而不是继续给 IDE 和聊天机器人增加功能？",[95,3213,3214],{},"研发任务跨越需求、代码、测试和协作系统时，系统应该用什么对象持续组织它？",[95,3216,3217],{},"开发数字员工如何像团队成员一样参与协作，同时保持权限、执行和责任边界？",[10,3219,3220],{},"本文尝试回答这三个问题，并进一步定义第一阶段真正要建设的产品。",[55,3222,3224],{"id":3223},"一开发人员缺少的不是又一个-ai-输入框","一、开发人员缺少的不是又一个 AI 输入框",[60,3226,3228],{"id":3227},"_11-研发工作天然分散在多个系统中","1.1 研发工作天然分散在多个系统中",[10,3230,3231],{},"一次真实的软件交付通常会经过如下过程：",[68,3233,3236],{"className":3234,"code":3235,"language":73,"meta":74},[71],"需求分析\n→ 技术方案设计\n→ 开发与自测\n→ Code Review\n→ 提测\n→ 测试执行\n→ 测试通过\n→ 上线准备\n→ 发布上线\n",[76,3237,3235],{"__ignoreMap":74},[10,3239,3240],{},"这条流程不会完整地存在于任何单一工具中。",[92,3242,3243,3246,3249,3252,3255,3258],{},[95,3244,3245],{},"需求和 Bug 可能在云效等项目协作平台中。",[95,3247,3248],{},"讨论和临时反馈可能发生在飞书群。",[95,3250,3251],{},"代码、Commit 和 PR\u002FMR 在代码托管平台中。",[95,3253,3254],{},"构建、测试和部署结果在 CI\u002FCD 系统中。",[95,3256,3257],{},"技术方案、接口说明和操作手册分散在文档平台与代码仓库中。",[95,3259,3260],{},"开发人员还可能在 IDE、命令行和 Coding Agent 之间切换。",[10,3262,3263],{},"这些系统分别保存了一部分事实，却没有共同维护“这项研发工作现在进行到哪里、已经产生了什么、还缺少什么证据”。",[10,3265,3266],{},"结果是，开发人员承担了大量隐性的上下文搬运工作：从群消息中找到问题描述，到项目系统确认需求和负责人，再定位相关代码和 PR，检查 CI 与测试环境，最后回到原系统更新状态。",[10,3268,3269],{},"AI 可以帮助分析其中某一步，但如果它只能在一次对话中工作，仍然无法持续承担跨系统协作。",[60,3271,3273],{"id":3272},"_12-ide聊天机器人与工作台解决的是不同问题","1.2 IDE、聊天机器人与工作台解决的是不同问题",[10,3275,3276],{},"IDE 和 Coding Agent 擅长操作代码：理解仓库、编辑文件、执行命令、补充测试和生成 Diff。聊天机器人擅长交互式理解、解释和生成内容。这两类产品都很重要，但它们通常以“当前会话”或“当前代码仓库”为中心。",[10,3278,3279],{},"研发交付却以业务任务为中心，并且持续时间可能跨越数小时甚至数天。任务会等待 Code Review、CI、测试环境、其他团队反馈或人工审批；任务状态不会因为对话结束而消失，也不能仅靠模型上下文恢复。",[10,3281,3282],{},"智能开发人员工作台要解决的不是“如何再提供一个调用模型的入口”，而是：",[29,3284,3285],{},[10,3286,3287],{},"如何让分散在需求、协作、代码、CI 和测试环境中的信息，围绕同一项研发工作持续汇聚；并让人、Agent 与企业系统在清晰边界内共同推进它。",[10,3289,3290],{},"因此，工作台位于各类研发工具之上，但不替代它们。",[68,3292,3295],{"className":3293,"code":3294,"language":73,"meta":74},[71],"开发人员 \u002F 测试人员 \u002F 负责人\n                 │\n                 ▼\n        智能开发人员工作台\n   任务 \u002F 上下文 \u002F 产物 \u002F 执行 \u002F 证据\n        │       │       │       │\n        ▼       ▼       ▼       ▼\n      云效     飞书   Git\u002FPR    CI\u002F环境\n                         │\n                         ▼\n                    Coding Agent\n",[76,3296,3294],{"__ignoreMap":74},[10,3298,3299],{},"它的价值不是把所有系统重新做一遍，而是提供统一的任务视角、可靠的协作状态和受控的智能执行能力。",[60,3301,3303],{"id":3302},"_13-工作台与开发数字员工是什么关系","1.3 工作台与开发数字员工是什么关系",[10,3305,3306],{},"工作台不是开发数字员工的一个聊天页面，开发数字员工也不是工作台里的一项普通工具。",[10,3308,3309],{},"两者的关系更接近“员工”与“工作环境”：",[92,3311,3312,3317,3322,3328,3334],{},[95,3313,3314,3316],{},[19,3315,3196],{},"是研发流程中的参与者，拥有持续身份、明确角色、职责范围和可审计的工作记录。",[95,3318,3319,3321],{},[19,3320,3178],{},"是它与人协作的任务、上下文、执行和治理底座。",[95,3323,3324,3327],{},[19,3325,3326],{},"飞书群","是接收信息、澄清问题和反馈进展的协作入口之一。",[95,3329,3330,3333],{},[19,3331,3332],{},"云效、代码仓库和 CI\u002FCD","是它读取或更新业务事实的工作系统。",[95,3335,3336,3338],{},[19,3337,1980],{},"是它完成代码分析与修改时可以调用的专业执行器，而不是数字员工的全部。",[68,3340,3343],{"className":3341,"code":3342,"language":73,"meta":74},[71],"飞书群中的开发数字员工\n  ├── 接收 @消息、Bug 反馈和任务指派\n  ├── 识别意图、补充信息、反馈进展\n  └── 创建或关联 WorkItem\n                    │\n                    ▼\n          智能开发人员工作台\n  任务 \u002F 上下文 \u002F 方案 \u002F 执行 \u002F 证据 \u002F 审批\n        │            │             │\n        ▼            ▼             ▼\n      云效       Coding Agent    Git \u002F CI\n",[76,3344,3342],{"__ignoreMap":74},[10,3346,3347],{},"因此，“像员工一样”并不只是拥有一个拟人化头像或能够在群里回复消息。它至少意味着：身份长期存在，能够被分配任务，知道自己负责哪些项目，可以在任务中持续工作，遇到权限或信息不足时主动请求帮助，并对每次行动留下可追踪记录。",[10,3349,3350,3351,3354],{},"群聊只是协作入口，不是任务状态的保存位置。开发数字员工从群消息中识别出工作后，仍然要将其关联到 ",[76,3352,3353],{},"WorkItem","，后续的技术方案、代码修改、PR\u002FMR、测试结果和人工决定才能持续归属于同一项研发任务。",[55,3356,3358],{"id":3357},"二产品中心不是聊天会话而是-workitem","二、产品中心不是聊天会话，而是 WorkItem",[60,3360,3362],{"id":3361},"_21-为什么需要统一的研发任务对象","2.1 为什么需要统一的研发任务对象",[10,3364,3365],{},"需求、开发任务和 Bug 在外部平台中可能是不同类型的记录，但从工作台视角看，它们都代表一项需要被持续推进、产生交付物并最终验证的工作。",[10,3367,3368,3369,1271],{},"本文将这个统一的协作对象称为 ",[76,3370,3353],{},[10,3372,3373,3375],{},[76,3374,3353],{}," 不是某条云效 Bug 的简单复制，也不是一段 Agent 对话。它是工作台内部可持久化的研发协作单元，负责把跨系统对象关联到同一条交付主线上。",[68,3377,3380],{"className":3378,"code":3379,"language":73,"meta":74},[71],"WorkItem\n├── 原始需求与验收标准\n├── 项目、模块、环境与负责人\n├── 技术方案与开发计划\n├── 分支、Commit 与 PR\u002FMR\n├── 自测、CI 与测试环境结果\n├── Code Review 意见\n├── 云效 Bug 与飞书反馈\n├── Agent 执行和修复记录\n└── 发布及最终验证证据\n",[76,3381,3379],{"__ignoreMap":74},[10,3383,3384],{},"例如，测试人员在飞书群反馈一个问题，云效中随后创建了一条 Bug，开发人员完成修复并提交 Draft PR，CI 通过后部署到测试环境。表面上这是五个系统中的多个对象，实际上它们属于同一个修复任务。",[10,3386,3387,3388,3390,3391,3393],{},"如果没有 ",[76,3389,3353],{},"，Agent 每次都要重新猜测这些对象是否相关；如果有 ",[76,3392,3353],{},"，系统就可以保存它们的确定性关联、当前状态和验证证据。",[60,3395,3397],{"id":3396},"_22-workitem-不是新的外部事实来源","2.2 WorkItem 不是新的外部事实来源",[10,3399,3400],{},"建立统一任务模型时，一个常见误区是试图用工作台取代现有研发系统。",[10,3402,3403],{},"工作台不应该宣布自己拥有所有事实：",[92,3405,3406,3409,3412,3415],{},[95,3407,3408],{},"云效仍然是需求和 Bug 原始记录及业务状态的重要来源。",[95,3410,3411],{},"Git 平台仍然保存分支、Commit、PR\u002FMR 和 Review 事实。",[95,3413,3414],{},"CI\u002FCD 系统仍然保存构建、测试和部署结果。",[95,3416,3417],{},"飞书仍然保存原始讨论与反馈消息。",[10,3419,3420,3421,3424],{},"工作台保存的是跨系统的",[19,3422,3423],{},"协调事实","：这些外部对象属于哪个任务、当前流程等待什么、某次判断依据了哪些上下文、某项操作是否获得批准，以及什么证据支持任务进入下一状态。",[10,3426,3427],{},"这意味着 WorkItem 既不是简单的数据镜像，也不是凌驾于所有系统之上的“超级主数据”。它更像一条可追踪的研发协作主线：引用外部事实，保存必要快照，并对跨系统流程负责。",[60,3429,3431],{"id":3430},"_23-核心领域对象","2.3 核心领域对象",[10,3433,3434,3435,3437],{},"围绕 ",[76,3436,3353],{},"，工作台至少需要以下对象：",[403,3439,3440,3450],{},[406,3441,3442],{},[409,3443,3444,3447],{},[412,3445,3446],{},"对象",[412,3448,3449],{},"主要职责",[419,3451,3452,3462,3472,3481,3490,3499,3508,3517,3526,3536],{},[409,3453,3454,3459],{},[424,3455,3456],{},[76,3457,3458],{},"Project",[424,3460,3461],{},"描述项目、代码仓库、模块、环境、团队与外部系统配置",[409,3463,3464,3469],{},[424,3465,3466],{},[76,3467,3468],{},"DigitalEmployee",[424,3470,3471],{},"描述数字员工的角色、身份、职责、授权项目、工具能力与运行策略",[409,3473,3474,3478],{},[424,3475,3476],{},[76,3477,3353],{},[424,3479,3480],{},"表示需求、开发任务或 Bug，以及当前生命周期状态",[409,3482,3483,3487],{},[424,3484,3485],{},[76,3486,2367],{},[424,3488,3489],{},"保存一次理解或执行实际使用的需求、代码、文档、日志和历史信息",[409,3491,3492,3496],{},[424,3493,3494],{},[76,3495,2373],{},[424,3497,3498],{},"表示技术方案、代码变更、Commit、PR\u002FMR、测试报告等产物",[409,3500,3501,3505],{},[424,3502,3503],{},[76,3504,2379],{},[424,3506,3507],{},"记录一次 Workflow、Agent、Coding Agent 或工具执行",[409,3509,3510,3514],{},[424,3511,3512],{},[76,3513,2385],{},[424,3515,3516],{},"表示编译、测试、CI、Review、部署和回归等验证结果",[409,3518,3519,3523],{},[424,3520,3521],{},[76,3522,2391],{},[424,3524,3525],{},"记录人工确认点、审批对象、结论及适用范围",[409,3527,3528,3533],{},[424,3529,3530],{},[76,3531,3532],{},"DomainEvent",[424,3534,3535],{},"记录任务状态变化和接收到的外部事件",[409,3537,3538,3542],{},[424,3539,3540],{},[76,3541,2397],{},[424,3543,3544],{},"保存有来源、作用域、验证状态和生命周期的可复用经验",[10,3546,3547],{},"这些对象并不是为了制造复杂的数据模型，而是为了避免把所有内容都塞进一段对话历史或一个巨大的任务 JSON 中。",[10,3549,3550,3552,3553,3555],{},[76,3551,3353],{}," 仍然是业务中心，",[76,3554,3468],{}," 则是任务参与者。一个开发数字员工可以同时参与多个 WorkItem，一个 WorkItem 也可能由开发人员、开发数字员工、测试人员和负责人共同推进。系统需要分别记录任务归属、当前执行者和最终责任人，不能因为数字员工执行了某一步，就模糊人的责任边界。",[60,3557,3559],{"id":3558},"_24-contextartifactevidence-和-memory-不能混为一谈","2.4 Context、Artifact、Evidence 和 Memory 不能混为一谈",[10,3561,3562],{},"这四类对象看起来相近，但承担不同职责。",[10,3564,3565,3567],{},[76,3566,2367],{}," 回答“这次判断使用了什么”。例如需求描述、相关代码片段、项目规范、日志和历史 Bug。它应当记录来源、获取时间和适用范围，以便之后解释 Agent 为什么得出某个结论。",[10,3569,3570,3572],{},[76,3571,2373],{}," 回答“这次工作产生了什么”。例如技术方案、修改后的代码、Commit、Draft PR、测试用例和报告。",[10,3574,3575,3577],{},[76,3576,2385],{}," 回答“凭什么认为某个条件已经满足”。编译成功、单元测试通过、CI 检查结果、部署记录、Code Review 结论和测试回归结果，都属于证据。",[10,3579,3580,3582],{},[76,3581,2397],{}," 回答“哪些经验可以在未来复用”。它不应该自动等于历史对话或历史修复方案。只有来源明确、经过验证且仍在有效期内的经验，才适合晋升为团队记忆。",[10,3584,3585],{},"这种区分还有一个实际意义：证据必须绑定明确的对象版本。某个 Commit 上通过的测试，不能自动证明后续修改后的 Commit 仍然正确；针对旧 Diff 的审批，也不能无条件覆盖新的代码变更。",[55,3587,3589],{"id":3588},"三研发任务的状态不是一个完成按钮","三、研发任务的状态不是一个“完成”按钮",[60,3591,3593],{"id":3592},"_31-通用生命周期与业务子流程","3.1 通用生命周期与业务子流程",[10,3595,3596],{},"不同团队会使用不同的研发状态。工作台不应一开始就强迫所有团队接受一套僵硬流程，但仍然需要一个最小的内部生命周期，用于判断任务是正在推进、等待外部结果、被阻塞还是已经结束。",[68,3598,3601],{"className":3599,"code":3600,"language":73,"meta":74},[71],"待处理 → 处理中 → 等待外部结果 → 已完成\n              ├── 被阻塞\n              └── 已取消\n",[76,3602,3600],{"__ignoreMap":74},[10,3604,3605],{},"在这层通用状态下，可以针对不同任务类型建立更具体的业务子流程，例如需求交付、技术方案评审或 Bug 修复。",[60,3607,3609],{"id":3608},"_32-测试阶段-bug-闭环","3.2 测试阶段 Bug 闭环",[10,3611,3612],{},"第一个重点场景发生在 Code Review 和上线之间。开发人员完成 CR 并提测后，测试人员可能在飞书群反馈问题，也可能直接在云效创建或更新 Bug。",[10,3614,3615],{},"完整的处理过程是：",[68,3617,3620],{"className":3618,"code":3619,"language":73,"meta":74},[71],"测试反馈或云效 Bug\n→ 识别、去重与关联\n→ 问题分析和代码修复\n→ 自测\n→ 必要的增量 Code Review\n→ 部署测试环境\n→ 将 Bug 标记为“已修复”\n→ 测试人员回归验证\n├── 通过：关闭 Bug\n└── 失败：重新打开 Bug，恢复原修复任务\n",[76,3621,3619],{"__ignoreMap":74},[10,3623,3624,3625,3628],{},"“已修复”也不等于“已关闭”。前者表达开发侧已经提供候选修复，后者表达测试回归已经确认问题解决。类似的区别在成熟工作项系统中也普遍存在：例如 Azure DevOps 将 ",[76,3626,3627],{},"Resolved"," 类状态用于“工作完成但等待验证”的阶段，而不是直接视为最终关闭。",[60,3630,3632],{"id":3631},"_33-状态变化必须由证据支持","3.3 状态变化必须由证据支持",[10,3634,3635],{},"如果工作台只是让 Agent 修改状态，它并不会比普通自动化更可信。",[10,3637,3638],{},"每个关键状态变化都应有明确的进入条件：",[403,3640,3641,3651],{},[406,3642,3643],{},[409,3644,3645,3648],{},[412,3646,3647],{},"状态变化",[412,3649,3650],{},"最小证据示例",[419,3652,3653,3661,3669,3677,3685,3693],{},[409,3654,3655,3658],{},[424,3656,3657],{},"开始修复",[424,3659,3660],{},"已确认问题归属、目标项目和代码仓库",[409,3662,3663,3666],{},[424,3664,3665],{},"创建 Draft PR\u002FMR",[424,3667,3668],{},"Diff、变更说明、自测结果与剩余风险",[409,3670,3671,3674],{},[424,3672,3673],{},"等待测试回归",[424,3675,3676],{},"必要检查通过、代码已部署至目标测试环境",[409,3678,3679,3682],{},[424,3680,3681],{},"标记为已修复",[424,3683,3684],{},"云效更新结果得到确认，且关联正确版本",[409,3686,3687,3690],{},[424,3688,3689],{},"关闭 Bug",[424,3691,3692],{},"测试人员或授权系统给出回归通过结果",[409,3694,3695,3698],{},[424,3696,3697],{},"重新打开",[424,3699,3700],{},"回归失败记录及失败版本、环境和现象",[10,3702,3703],{},"因此，“Agent 已执行”“代码已生成”或“PR 已创建”都不能单独代表任务完成。任务完成必须由业务可接受的结果和可追踪证据共同定义。",[55,3705,3707],{"id":3706},"四谁负责判断谁负责执行谁保存最终事实","四、谁负责判断，谁负责执行，谁保存最终事实",[10,3709,3710],{},"企业 Agent 系统最重要的边界之一，是不要把所有职责都交给模型。",[10,3712,3713],{},"一个较稳定的原则是：",[29,3715,3716],{},[10,3717,3718],{},"模型提出判断和行动建议，确定性程序负责验证与执行约束，企业业务系统保存各自领域的最终事实，人在高风险或高歧义节点负责决定。",[60,3720,3722],{"id":3721},"_41-模型和-agent-适合处理什么","4.1 模型和 Agent 适合处理什么",[10,3724,3725],{},"模型擅长处理语义理解和开放性问题，例如：",[92,3727,3728,3731,3734,3737,3740,3743,3746],{},[95,3729,3730],{},"从飞书消息中判断是否包含 Bug 反馈。",[95,3732,3733],{},"从需求、代码、日志和文档中提取相关上下文。",[95,3735,3736],{},"识别可能重复或相关的问题。",[95,3738,3739],{},"分析候选原因并形成修复计划。",[95,3741,3742],{},"调用 Coding Agent 修改代码、补充测试。",[95,3744,3745],{},"总结 Diff、测试结果、风险和待确认事项。",[95,3747,3748],{},"为开发人员提供下一步行动建议。",[10,3750,3751],{},"这些输出通常具有概率性。即使结果看起来合理，也需要通过权限、规则、测试或人工评审验证。",[60,3753,3755],{"id":3754},"_42-确定性程序必须承担什么","4.2 确定性程序必须承担什么",[10,3757,3758],{},"以下能力不应依赖模型“记住”或“自觉遵守”：",[92,3760,3761,3764,3767,3770,3773,3776,3779],{},[95,3762,3763],{},"外部事件验签、接收、去重和顺序控制。",[95,3765,3766],{},"WorkItem 状态机与合法状态转换。",[95,3768,3769],{},"用户身份、服务身份和权限检查。",[95,3771,3772],{},"项目、仓库、分支、Commit、PR\u002FMR 和 CI 的确定性关联。",[95,3774,3775],{},"外部 API 调用、幂等键、重试和结果确认。",[95,3777,3778],{},"审批检查点、超时、取消和恢复。",[95,3780,3781],{},"证据完整性以及验收条件判断。",[10,3783,3784],{},"例如，当创建 Draft PR 的请求超时，系统不能简单重试，否则可能创建两个 PR。正确做法是先查询外部系统，确认操作是否已经成功，再决定是否补偿或重试。",[60,3786,3788],{"id":3787},"_43-企业系统负责什么","4.3 企业系统负责什么",[10,3790,3791],{},"工作台不应绕开现有企业系统的规则。",[92,3793,3794,3797,3800,3803],{},[95,3795,3796],{},"云效决定 Bug 是否真的更新成功，以及当前业务状态是什么。",[95,3798,3799],{},"Git 平台决定 Commit、PR\u002FMR、Review 和合并状态。",[95,3801,3802],{},"CI\u002FCD 系统决定某次构建、测试和部署是否成功。",[95,3804,3805],{},"身份系统决定用户和服务账号的有效身份与授权范围。",[10,3807,3808],{},"工作台可以编排这些系统，但不能用自己的推断伪造外部成功。",[60,3810,3812],{"id":3811},"_44-人必须保留哪些决定","4.4 人必须保留哪些决定",[10,3814,3815],{},"第一阶段至少应保留以下人工检查点：",[92,3817,3818,3821,3824,3827,3830,3833],{},[95,3819,3820],{},"需求存在重大歧义或验收标准不足。",[95,3822,3823],{},"Agent 请求访问新的仓库、环境或敏感数据。",[95,3825,3826],{},"代码修改影响高风险模块。",[95,3828,3829],{},"测试证据不足，或者自动化检查结果互相冲突。",[95,3831,3832],{},"PR\u002FMR 合并和生产环境发布。",[95,3834,3835],{},"是否将一次修复经验晋升为团队长期记忆。",[10,3837,3838],{},"初期系统只创建 Draft PR\u002FMR，不自动合并，也不自动发布生产环境。自主程度应当由任务风险、证据质量和组织策略共同决定，而不是由 Agent 能否调用某个工具决定。",[60,3840,3842],{"id":3841},"_45-数字员工需要身份职责与授权","4.5 数字员工需要身份、职责与授权",[10,3844,3845],{},"开发数字员工要进入飞书群并参与真实项目，首先需要成为企业系统中可识别、可约束的主体。",[10,3847,3848],{},"它的身份至少包含三个层次：",[92,3850,3851,3857,3863],{},[95,3852,3853,3856],{},[19,3854,3855],{},"协作身份","：在飞书中以明确的数字员工身份加入授权群聊，接收 @消息、任务指派或经过配置的事件，并向群内反馈进展。",[95,3858,3859,3862],{},[19,3860,3861],{},"业务角色","：作为“开发”参与指定项目，能够设计技术方案、分析和修复问题、编写代码并提交 Draft PR\u002FMR。",[95,3864,3865,3868],{},[19,3866,3867],{},"系统凭证","：通过受限的服务身份访问云效、代码仓库、CI\u002FCD 和文档系统，不直接继承某个开发人员的全部权限。",[10,3870,3871],{},"身份存在不代表拥有无限访问权。系统仍然需要明确它可以加入哪些群、处理哪些项目、读取哪些仓库、调用哪些工具、执行到什么阶段，以及哪些动作必须由人确认。",[10,3873,3874],{},"同样，开发数字员工也不应默认处理群内所有内容。消息是否触发任务，可以由 @提及、指定群规则、明确任务指令或已配置事件共同决定；原始消息、触发原因和后续回复都应关联到对应 WorkItem。这样它既能像员工一样参与日常协作，又不会退化成监听所有聊天内容、凭自己判断任意执行的机器人。",[55,3876,3878],{"id":3877},"五外部系统的复杂性应该停留在适配层","五、外部系统的复杂性应该停留在适配层",[60,3880,3882],{"id":3881},"_51-用-provider-隔离平台差异","5.1 用 Provider 隔离平台差异",[10,3884,3885],{},"工作台可以定义一组面向领域的接口：",[68,3887,3890],{"className":3888,"code":3889,"language":73,"meta":74},[71],"WorkItemProvider       → 云效等需求与缺陷系统\nCollaborationProvider  → 飞书等协作系统\nRepositoryProvider     → GitLab、Codeup、GitHub 等代码平台\nPipelineProvider       → CI\u002FCD 与测试环境\nCodingAgentProvider    → Codex 或其他成熟 Coding Agent\n",[76,3891,3889],{"__ignoreMap":74},[10,3893,3894],{},"这些接口不应追求抹平所有平台能力，而应围绕当前用例提供最小、稳定的语义。例如核心层关心的是“获取某项目更新的 Bug”“关联外部工作项”“将 Bug 标记为已修复”，而不是某家平台具体使用了哪条 URL。",[10,3896,3897],{},"适配层还要负责：",[92,3899,3900,3903,3906,3909,3912],{},[95,3901,3902],{},"外部标识映射。",[95,3904,3905],{},"原始状态与内部状态的转换。",[95,3907,3908],{},"Webhook、轮询和 API 响应的统一事件化。",[95,3910,3911],{},"限流、重试与错误分类。",[95,3913,3914],{},"保留原始事件和来源，支持审计与问题追踪。",[10,3916,3917],{},"这种边界不仅方便未来接入其他平台，更重要的是保护 WorkItem 生命周期不被某个供应商的接口模型绑架。",[55,3919,3921],{"id":3920},"六工作台的信息架构应该映射领域模型","六、工作台的信息架构应该映射领域模型",[10,3923,3924],{},"如果产品中心是 WorkItem，那么页面结构也应该围绕研发任务，而不是围绕技术组件或 Agent 名称设计。",[10,3926,3927],{},"第一阶段可以包含以下区域：",[60,3929,3931],{"id":3930},"_61-工作台概览","6.1 工作台概览",[10,3933,3934],{},"展示人和开发数字员工当前需要关注的研发任务：处理中、等待 Review、等待 CI、等待测试回归、被阻塞和最近完成。概览页首先回答“现在有哪些事情需要处理、正在由谁处理”，而不是展示模型调用次数。",[60,3936,3938],{"id":3937},"_62-数字员工","6.2 数字员工",[10,3940,3941],{},"首版只提供一个“开发”数字员工角色，展示其工作身份、职责说明、授权项目和群聊、可用工具、当前任务、等待事项、近期执行和人工接管入口。",[10,3943,3944],{},"这里不是创建任意 Agent 的市场，也不需要一开始就支持复杂的角色编排。它首先要让团队看清楚：这个数字员工是谁，能做什么，正在做什么，为什么暂停，以及人如何接管。",[60,3946,3948],{"id":3947},"_63-研发任务","6.3 研发任务",[10,3950,3951],{},"提供 WorkItem 列表和详情页。详情页集中展示：",[92,3953,3954,3957,3960,3963,3966,3969,3972],{},[95,3955,3956],{},"当前状态、负责人和下一步动作。",[95,3958,3959],{},"需求、Bug 和原始反馈。",[95,3961,3962],{},"关联分支、Commit、PR\u002FMR 和环境。",[95,3964,3965],{},"时间线。",[95,3967,3968],{},"产物和证据。",[95,3970,3971],{},"Agent 与工具执行记录。",[95,3973,3974],{},"人工审批及其适用版本。",[60,3976,3978],{"id":3977},"_64-bug-闭环","6.4 Bug 闭环",[10,3980,3981],{},"这是围绕测试阶段建立的业务视图，重点呈现从发现、修复、标记已修复到回归关闭或重新打开的全过程。它不是另一套任务数据，而是 WorkItem 在特定业务流程下的视图。",[60,3983,3985],{"id":3984},"_65-执行记录","6.5 执行记录",[10,3987,3988,3989,3991],{},"展示 Workflow、Agent、Coding Agent 和工具调用产生的 ",[76,3990,2379],{},"，包括输入上下文、使用的权限、过程日志、产物、耗时、成本与结果。",[60,3993,3995],{"id":3994},"_66-项目上下文","6.6 项目上下文",[10,3997,3998],{},"管理项目、模块、代码仓库、环境、团队、规范与上下文来源。它决定一个 WorkItem 在执行时可以访问什么，以及不同信息如何组合。",[60,4000,4002],{"id":4001},"_67-连接与集成","6.7 连接与集成",[10,4004,4005],{},"集中管理云效、飞书、Git、CI 和 Coding Agent。当前已实现的云效连接配置应归入这里，而不应成为整个工作台的首页或产品中心。",[60,4007,4009],{"id":4008},"_68-治理","6.8 治理",[10,4011,4012],{},"逐步加入身份、权限策略、审批规则、审计、记忆和评估。第一阶段可以只提供必要入口，不必提前建设一个完整治理平台。",[10,4014,4015],{},"这套信息架构背后的原则是：导航映射业务概念，技术能力服务于任务。Timeline、Evidence 和 Approval 是同一个 WorkItem 的不同观察角度，不应被拆成互不相关的功能孤岛。",[55,4017,4019],{"id":4018},"七第一阶段应该做到什么程度","七、第一阶段应该做到什么程度",[60,4021,4023],{"id":4022},"_71-iteration-0先建立没有-agent-也能运行的领域骨架","7.1 Iteration 0：先建立没有 Agent 也能运行的领域骨架",[10,4025,4026,4027,4029,4030,4029,4032,4029,4034,4029,4036,4029,4038,4029,4040,4029,4042,4044],{},"第一阶段首先实现 ",[76,4028,3458],{},"、",[76,4031,3468],{},[76,4033,3353],{},[76,4035,2373],{},[76,4037,2385],{},[76,4039,2391],{},[76,4041,2379],{},[76,4043,3532],{},"、状态流和时间线，外部平台可以使用模拟适配器。此时的开发数字员工可以先由模拟执行器驱动，不必等待完整 Agent 能力才能验证任务归属、协作和状态模型。",[10,4046,4047],{},"退出条件不是“页面已经搭好”，而是无需模型参与，也能够完整模拟以下过程：",[68,4049,4052],{"className":4050,"code":4051,"language":73,"meta":74},[71],"开发 → Code Review → 提测 → 测试发现 Bug\n→ 修复 → 标记已修复 → 回归关闭或重新打开\n",[76,4053,4051],{"__ignoreMap":74},[10,4055,4056],{},"这一步能验证领域模型是否稳定，也能避免核心业务状态被某个 Agent 框架或外部平台结构主导。",[60,4058,4060],{"id":4059},"_72-iteration-1从任务到可验证的-draft-prmr","7.2 Iteration 1：从任务到可验证的 Draft PR\u002FMR",[10,4062,4063],{},"随后接入成熟 Coding Agent，实现任务上下文组装、隔离工作区、代码修改、测试执行、Diff 和证据收集，并在人工确认后创建 Draft PR\u002FMR。",[10,4065,4066],{},"退出条件是：一个预置任务能够产生可审查的 Draft PR\u002FMR，并附带测试证据、变更说明和剩余风险，而不是只生成一段代码。",[60,4068,4070],{"id":4069},"_73-iteration-2接通真实的主动式-bug-闭环","7.3 Iteration 2：接通真实的主动式 Bug 闭环",[10,4072,4073],{},"最后让开发数字员工以明确身份接入飞书、云效、代码平台与 CI\u002FCD：",[92,4075,4076,4079,4082,4085,4088,4091,4094,4097],{},[95,4077,4078],{},"在授权群聊中接收 @消息、Bug 反馈或任务指派。",[95,4080,4081],{},"从飞书反馈或云效事件中发现问题，并创建或关联 WorkItem。",[95,4083,4084],{},"对重复事件和重复问题进行去重、关联。",[95,4086,4087],{},"触发受控的分析与修复。",[95,4089,4090],{},"设计技术方案或修复方案，必要时向人补充提问。",[95,4092,4093],{},"跟踪必要的增量 CR、CI 和测试环境部署。",[95,4095,4096],{},"满足条件后将 Bug 标记为已修复。",[95,4098,4099],{},"等待测试人员回归，通过则关闭，失败则重新打开并恢复原任务。",[10,4101,4102],{},"退出条件包括：重复事件不会创建重复任务；进程重启不会丢失状态；外部结果不确定时能够先查询确认；回归失败后可以从已有上下文和证据继续处理。",[55,4104,2800],{"id":2799},[10,4106,4107],{},"为了让产品边界保持清晰，第一阶段不追求以下目标：",[92,4109,4110,4113,4116,4119,4122,4125,4128,4131,4134,4137],{},[95,4111,4112],{},"不重新开发一个完整的项目管理、代码托管或 CI\u002FCD 平台。",[95,4114,4115],{},"不在首版同时设计多个数字员工角色，先验证“开发”这一类角色。",[95,4117,4118],{},"不从零开发完整 Coding Agent，而是通过适配器接入成熟执行器。",[95,4120,4121],{},"不让聊天历史承担任务状态和长期流程恢复。",[95,4123,4124],{},"不因为技术上能调用工具，就默认允许自主执行。",[95,4126,4127],{},"不为了展示 Multi-Agent 而人为拆分多个角色。",[95,4129,4130],{},"不自动合并 PR\u002FMR，不自动发布生产环境。",[95,4132,4133],{},"不把 Agent 推测直接写成企业事实或团队长期记忆。",[95,4135,4136],{},"不在缺少证据时把“已执行”解释成“已完成”。",[95,4138,4139],{},"不提前把暂定框架和技术选型写成不可替换的系统边界。",[10,4141,4142],{},"首版真正需要证明的是：以 WorkItem 为中心的任务模型，能否让跨系统研发协作持续、可控、可恢复和可验证。",[55,4144,4146],{"id":4145},"九总结工作台是研发数字员工的任务底座","九、总结：工作台是研发数字员工的任务底座",[10,4148,4149],{},"智能开发人员工作台并不是给现有后台加一个 AI 对话框，也不是把云效、飞书、代码仓库和 CI 页面集中放进同一个导航栏。它要支撑的第一个真实角色，是能够进入团队协作环境并持续承担研发任务的开发数字员工。",[10,4151,4152],{},"它的核心是建立一条跨系统、跨阶段的研发任务主线：",[92,4154,4155,4161,4166,4171,4176,4181,4186,4191],{},[95,4156,4157,4158,4160],{},"用 ",[76,4159,3353],{}," 表示需要持续推进的工作。",[95,4162,4157,4163,4165],{},[76,4164,2367],{}," 记录判断所依据的信息。",[95,4167,4157,4168,4170],{},[76,4169,2373],{}," 保存过程中产生的交付物。",[95,4172,4157,4173,4175],{},[76,4174,2379],{}," 记录人、Agent 和工具执行了什么。",[95,4177,4157,4178,4180],{},[76,4179,2385],{}," 证明状态为什么可以向前推进。",[95,4182,4157,4183,4185],{},[76,4184,2391],{}," 保留必要的人工决定。",[95,4187,4157,4188,4190],{},[76,4189,3532],{}," 连接外部变化和内部生命周期。",[95,4192,4193,4194,4196],{},"用经过验证的 ",[76,4195,2397],{}," 支持未来任务，而不是积累不可控的历史猜测。",[10,4198,4199],{},"在这个模型中，模型和 Agent 提供理解、推理与候选行动；确定性程序维护状态、权限、幂等和验收条件；企业系统保存各自领域的最终事实；人负责高风险、高歧义和最终责任节点。",[10,4201,4202],{},"开发数字员工可以在飞书中接收任务和反馈，设计技术方案，调用 Coding Agent 编写与测试代码，提交 Draft PR\u002FMR，并在等待 Review、CI 或测试回归期间持续跟踪任务。工作台则让它的身份、权限、上下文、行动和结果始终处于可见、可控和可审计的状态。",[10,4204,4205],{},"只有先建立这样的任务底座，自动修复测试阶段 Bug 才不会退化成一段脆弱的自动化脚本，研发 Agent 也才可能从一次性助手逐步演进为能够长期参与企业协作的数字员工。完成“开发”这一角色的验证后，同一套底座才有可能扩展到测试、运维或其他企业数字员工。",[10,4207,4208,4209],{},"下一篇将继续讨论一个更具体的问题：",[19,4210,4211],{},"研发流程中哪些环节应该使用 Workflow，哪些应该交给 Agent？",[55,4213,1024],{"id":1024},[1026,4215,4216,4222,4230,4238,4252,4260,4268,4276,4284],{},[95,4217,4218,4221],{},[1031,4219,1154],{"href":3164,"rel":4220},[1035]," — 本系列首篇，介绍企业 Agent 的需求、挑战、架构目标和项目总体定位。",[95,4223,4224,4229],{},[1031,4225,4228],{"href":4226,"rel":4227},"https:\u002F\u002Fwww.zhizhi123.com\u002Fblog\u002F2026\u002F10\u002F08\u002Fai-assisted-dev-workflow\u002F",[1035],"AI 辅助研发工作流"," — 从研发实践角度讨论需求、设计、开发、Review 与交付过程。",[95,4231,4232,4237],{},[1031,4233,4236],{"href":4234,"rel":4235},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fdevops\u002Fboards\u002Fwork-items\u002Fabout-work-items",[1035],"Microsoft Learn：About work items and work item types"," — 工作项类型、状态、历史以及与开发对象关联的官方说明。",[95,4239,4240,4245,4246,4029,4248,4251],{},[1031,4241,4244],{"href":4242,"rel":4243},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fdevops\u002Forganizations\u002Fsettings\u002Fwork\u002Fcustomize-process-workflow",[1035],"Microsoft Learn：Customize the workflow"," — 工作项状态流及 ",[76,4247,3627],{},[76,4249,4250],{},"Completed"," 等状态类别。",[95,4253,4254,4259],{},[1031,4255,4258],{"href":4256,"rel":4257},"https:\u002F\u002Fdocs.github.com\u002Fen\u002Fpull-requests\u002Fget-started\u002Fabout-pull-requests",[1035],"GitHub Docs：About pull requests"," — Pull Request 在代码讨论、Review 与合并流程中的作用。",[95,4261,4262,4267],{},[1031,4263,4266],{"href":4264,"rel":4265},"https:\u002F\u002Fdocs.github.com\u002Fen\u002Fpull-requests\u002Freference\u002Fstatus-checks",[1035],"GitHub Docs：Status checks"," — 构建、测试、代码扫描和部署检查如何为变更提供验证信号。",[95,4269,4270,4275],{},[1031,4271,4274],{"href":4272,"rel":4273},"https:\u002F\u002Fcloudevents.io\u002F",[1035],"CloudEvents Specification"," — 跨系统事件的通用描述规范。",[95,4277,4278,4283],{},[1031,4279,4282],{"href":4280,"rel":4281},"https:\u002F\u002Fopentelemetry.io\u002Fdocs\u002F",[1035],"OpenTelemetry Documentation"," — Trace、Metric 和 Log 等可观测性基础。",[95,4285,4286,4290],{},[1031,4287,4289],{"href":3070,"rel":4288},[1035],"Model Context Protocol"," — Agent 访问工具和上下文资源的标准化协议；它不替代业务状态、权限和验收流程。",{"title":74,"searchDepth":1095,"depth":1095,"links":4292},[4293,4298,4304,4309,4316,4319,4329,4334,4335,4336],{"id":3223,"depth":1095,"text":3224,"children":4294},[4295,4296,4297],{"id":3227,"depth":1100,"text":3228},{"id":3272,"depth":1100,"text":3273},{"id":3302,"depth":1100,"text":3303},{"id":3357,"depth":1095,"text":3358,"children":4299},[4300,4301,4302,4303],{"id":3361,"depth":1100,"text":3362},{"id":3396,"depth":1100,"text":3397},{"id":3430,"depth":1100,"text":3431},{"id":3558,"depth":1100,"text":3559},{"id":3588,"depth":1095,"text":3589,"children":4305},[4306,4307,4308],{"id":3592,"depth":1100,"text":3593},{"id":3608,"depth":1100,"text":3609},{"id":3631,"depth":1100,"text":3632},{"id":3706,"depth":1095,"text":3707,"children":4310},[4311,4312,4313,4314,4315],{"id":3721,"depth":1100,"text":3722},{"id":3754,"depth":1100,"text":3755},{"id":3787,"depth":1100,"text":3788},{"id":3811,"depth":1100,"text":3812},{"id":3841,"depth":1100,"text":3842},{"id":3877,"depth":1095,"text":3878,"children":4317},[4318],{"id":3881,"depth":1100,"text":3882},{"id":3920,"depth":1095,"text":3921,"children":4320},[4321,4322,4323,4324,4325,4326,4327,4328],{"id":3930,"depth":1100,"text":3931},{"id":3937,"depth":1100,"text":3938},{"id":3947,"depth":1100,"text":3948},{"id":3977,"depth":1100,"text":3978},{"id":3984,"depth":1100,"text":3985},{"id":3994,"depth":1100,"text":3995},{"id":4001,"depth":1100,"text":4002},{"id":4008,"depth":1100,"text":4009},{"id":4018,"depth":1095,"text":4019,"children":4330},[4331,4332,4333],{"id":4022,"depth":1100,"text":4023},{"id":4059,"depth":1100,"text":4060},{"id":4069,"depth":1100,"text":4070},{"id":2799,"depth":1095,"text":2800},{"id":4145,"depth":1095,"text":4146},{"id":1024,"depth":1095,"text":1024},"wiki:agent:dev-workbench-product-positioning-task-model-system-boundary",{},"\u002Fagent\u002Fdev-workbench-product-positioning-task-model-system-boundary",{"title":3146,"description":3153},"agent\u002Fdev-workbench-product-positioning-task-model-system-boundary","2026-11-10","h6kk--ZGBjDlyQHKahrN37Qt724TWSmwqmmpdzfPGDM",{"id":4,"title":5,"body":4345,"commentId":1140,"description":15,"draft":1141,"extension":1142,"meta":5126,"navigation":1144,"order":1100,"path":1145,"section":1146,"seo":5127,"stem":1148,"updated":1149,"__hash__":1150},{"type":7,"value":4346,"toc":5082},[4347,4351,4355,4357,4359,4363,4365,4369,4371,4373,4375,4377,4379,4381,4383,4388,4390,4392,4394,4396,4412,4414,4418,4420,4425,4427,4429,4431,4433,4435,4451,4453,4455,4457,4471,4473,4475,4480,4482,4484,4486,4500,4502,4504,4509,4511,4513,4515,4529,4531,4545,4547,4549,4551,4556,4558,4560,4562,4564,4566,4580,4582,4584,4586,4600,4602,4604,4606,4642,4644,4648,4650,4652,4654,4656,4661,4663,4665,4669,4671,4673,4675,4689,4691,4693,4695,4697,4702,4704,4709,4711,4713,4715,4717,4719,4721,4723,4735,4737,4739,4741,4743,4748,4750,4755,4757,4759,4764,4766,4771,4773,4775,4780,4782,4786,4788,4790,4792,4797,4799,4801,4806,4808,4810,4812,4817,4819,4821,4826,4828,4830,4832,4834,4888,4890,4895,4897,4902,4904,4906,4908,4913,4915,4917,4919,4941,4943,4947,4952,4954,4956,4958,4963,4965,4979,4981,4983,4985,4990,4992,4997,4999,5004,5006,5008,5010,5012,5024,5026,5028,5032,5034,5038,5040],[10,4348,4349],{},[13,4350,15],{},[10,4352,4353],{},[19,4354,21],{},[10,4356,24],{},[10,4358,27],{},[29,4360,4361],{},[10,4362,33],{},[10,4364,36],{},[10,4366,4367],{},[19,4368,41],{},[10,4370,44],{},[10,4372,47],{},[10,4374,50],{},[10,4376,53],{},[55,4378,58],{"id":57},[60,4380,63],{"id":62},[10,4382,66],{},[68,4384,4386],{"className":4385,"code":72,"language":73,"meta":74},[71],[76,4387,72],{"__ignoreMap":74},[10,4389,80],{},[60,4391,84],{"id":83},[10,4393,87],{},[10,4395,90],{},[92,4397,4398,4400,4402,4404,4406,4408,4410],{},[95,4399,97],{},[95,4401,100],{},[95,4403,103],{},[95,4405,106],{},[95,4407,109],{},[95,4409,112],{},[95,4411,115],{},[10,4413,118],{},[29,4415,4416],{},[10,4417,123],{},[10,4419,126],{},[68,4421,4423],{"className":4422,"code":130,"language":73,"meta":74},[71],[76,4424,130],{"__ignoreMap":74},[10,4426,135],{},[60,4428,139],{"id":138},[10,4430,142],{},[10,4432,145],{},[10,4434,148],{},[92,4436,4437,4439,4441,4443,4445,4447,4449],{},[95,4438,153],{},[95,4440,156],{},[95,4442,159],{},[95,4444,162],{},[95,4446,165],{},[95,4448,168],{},[95,4450,171],{},[10,4452,174],{},[60,4454,178],{"id":177},[10,4456,181],{},[92,4458,4459,4461,4463,4465,4467,4469],{},[95,4460,186],{},[95,4462,189],{},[95,4464,192],{},[95,4466,195],{},[95,4468,198],{},[95,4470,201],{},[10,4472,204],{},[10,4474,207],{},[68,4476,4478],{"className":4477,"code":211,"language":73,"meta":74},[71],[76,4479,211],{"__ignoreMap":74},[55,4481,217],{"id":216},[60,4483,221],{"id":220},[10,4485,224],{},[92,4487,4488,4490,4492,4494,4496,4498],{},[95,4489,229],{},[95,4491,232],{},[95,4493,235],{},[95,4495,238],{},[95,4497,241],{},[95,4499,244],{},[10,4501,247],{},[10,4503,250],{},[68,4505,4507],{"className":4506,"code":254,"language":73,"meta":74},[71],[76,4508,254],{"__ignoreMap":74},[10,4510,259],{},[60,4512,263],{"id":262},[10,4514,266],{},[92,4516,4517,4519,4521,4523,4525,4527],{},[95,4518,271],{},[95,4520,274],{},[95,4522,277],{},[95,4524,280],{},[95,4526,283],{},[95,4528,286],{},[10,4530,289],{},[92,4532,4533,4535,4537,4539,4541,4543],{},[95,4534,294],{},[95,4536,297],{},[95,4538,300],{},[95,4540,303],{},[95,4542,306],{},[95,4544,309],{},[10,4546,312],{},[60,4548,316],{"id":315},[10,4550,319],{},[68,4552,4554],{"className":4553,"code":323,"language":73,"meta":74},[71],[76,4555,323],{"__ignoreMap":74},[10,4557,328],{},[10,4559,331],{},[10,4561,334],{},[60,4563,338],{"id":337},[10,4565,341],{},[92,4567,4568,4570,4572,4574,4576,4578],{},[95,4569,346],{},[95,4571,349],{},[95,4573,352],{},[95,4575,355],{},[95,4577,358],{},[95,4579,361],{},[10,4581,364],{},[60,4583,368],{"id":367},[10,4585,371],{},[92,4587,4588,4590,4592,4594,4596,4598],{},[95,4589,376],{},[95,4591,379],{},[95,4593,382],{},[95,4595,385],{},[95,4597,388],{},[95,4599,391],{},[10,4601,394],{},[55,4603,398],{"id":397},[10,4605,401],{},[403,4607,4608,4616],{},[406,4609,4610],{},[409,4611,4612,4614],{},[412,4613,414],{},[412,4615,417],{},[419,4617,4618,4624,4630,4636],{},[409,4619,4620,4622],{},[424,4621,426],{},[424,4623,429],{},[409,4625,4626,4628],{},[424,4627,434],{},[424,4629,437],{},[409,4631,4632,4634],{},[424,4633,442],{},[424,4635,445],{},[409,4637,4638,4640],{},[424,4639,450],{},[424,4641,453],{},[10,4643,456],{},[29,4645,4646],{},[10,4647,461],{},[55,4649,465],{"id":464},[10,4651,468],{},[60,4653,472],{"id":471},[10,4655,475],{},[68,4657,4659],{"className":4658,"code":479,"language":73,"meta":74},[71],[76,4660,479],{"__ignoreMap":74},[10,4662,484],{},[10,4664,487],{},[29,4666,4667],{},[10,4668,492],{},[10,4670,495],{},[60,4672,499],{"id":498},[10,4674,502],{},[92,4676,4677,4679,4681,4683,4685,4687],{},[95,4678,507],{},[95,4680,510],{},[95,4682,513],{},[95,4684,516],{},[95,4686,519],{},[95,4688,522],{},[10,4690,525],{},[10,4692,528],{},[60,4694,532],{"id":531},[10,4696,535],{},[68,4698,4700],{"className":4699,"code":539,"language":73,"meta":74},[71],[76,4701,539],{"__ignoreMap":74},[10,4703,544],{},[68,4705,4707],{"className":4706,"code":548,"language":73,"meta":74},[71],[76,4708,548],{"__ignoreMap":74},[10,4710,553],{},[60,4712,557],{"id":556},[10,4714,560],{},[10,4716,563],{},[10,4718,566],{},[60,4720,570],{"id":569},[10,4722,573],{},[92,4724,4725,4727,4729,4731,4733],{},[95,4726,578],{},[95,4728,581],{},[95,4730,584],{},[95,4732,587],{},[95,4734,590],{},[10,4736,593],{},[55,4738,597],{"id":596},[10,4740,600],{},[60,4742,604],{"id":603},[68,4744,4746],{"className":4745,"code":608,"language":73,"meta":74},[71],[76,4747,608],{"__ignoreMap":74},[10,4749,126],{},[68,4751,4753],{"className":4752,"code":616,"language":73,"meta":74},[71],[76,4754,616],{"__ignoreMap":74},[10,4756,621],{},[60,4758,625],{"id":624},[68,4760,4762],{"className":4761,"code":629,"language":73,"meta":74},[71],[76,4763,629],{"__ignoreMap":74},[10,4765,126],{},[68,4767,4769],{"className":4768,"code":637,"language":73,"meta":74},[71],[76,4770,637],{"__ignoreMap":74},[10,4772,642],{},[60,4774,646],{"id":645},[68,4776,4778],{"className":4777,"code":650,"language":73,"meta":74},[71],[76,4779,650],{"__ignoreMap":74},[10,4781,655],{},[29,4783,4784],{},[10,4785,660],{},[10,4787,663],{},[55,4789,667],{"id":666},[60,4791,671],{"id":670},[68,4793,4795],{"className":4794,"code":675,"language":73,"meta":74},[71],[76,4796,675],{"__ignoreMap":74},[10,4798,680],{},[60,4800,684],{"id":683},[68,4802,4804],{"className":4803,"code":688,"language":73,"meta":74},[71],[76,4805,688],{"__ignoreMap":74},[10,4807,693],{},[10,4809,696],{},[60,4811,700],{"id":699},[68,4813,4815],{"className":4814,"code":704,"language":73,"meta":74},[71],[76,4816,704],{"__ignoreMap":74},[10,4818,709],{},[60,4820,713],{"id":712},[68,4822,4824],{"className":4823,"code":717,"language":73,"meta":74},[71],[76,4825,717],{"__ignoreMap":74},[10,4827,722],{},[10,4829,725],{},[55,4831,729],{"id":728},[10,4833,732],{},[403,4835,4836,4846],{},[406,4837,4838],{},[409,4839,4840,4842,4844],{},[412,4841,741],{},[412,4843,744],{},[412,4845,747],{},[419,4847,4848,4856,4864,4872,4880],{},[409,4849,4850,4852,4854],{},[424,4851,754],{},[424,4853,757],{},[424,4855,760],{},[409,4857,4858,4860,4862],{},[424,4859,765],{},[424,4861,768],{},[424,4863,771],{},[409,4865,4866,4868,4870],{},[424,4867,776],{},[424,4869,779],{},[424,4871,782],{},[409,4873,4874,4876,4878],{},[424,4875,787],{},[424,4877,790],{},[424,4879,793],{},[409,4881,4882,4884,4886],{},[424,4883,798],{},[424,4885,801],{},[424,4887,804],{},[10,4889,807],{},[68,4891,4893],{"className":4892,"code":811,"language":73,"meta":74},[71],[76,4894,811],{"__ignoreMap":74},[10,4896,816],{},[68,4898,4900],{"className":4899,"code":820,"language":73,"meta":74},[71],[76,4901,820],{"__ignoreMap":74},[55,4903,826],{"id":825},[60,4905,830],{"id":829},[10,4907,833],{},[68,4909,4911],{"className":4910,"code":837,"language":73,"meta":74},[71],[76,4912,837],{"__ignoreMap":74},[10,4914,842],{},[60,4916,846],{"id":845},[10,4918,849],{},[92,4920,4921,4923,4925,4927,4929,4931,4933,4935,4937,4939],{},[95,4922,854],{},[95,4924,857],{},[95,4926,860],{},[95,4928,863],{},[95,4930,866],{},[95,4932,869],{},[95,4934,872],{},[95,4936,875],{},[95,4938,878],{},[95,4940,881],{},[60,4942,885],{"id":884},[10,4944,888,4945,892],{},[76,4946,891],{},[68,4948,4950],{"className":4949,"code":896,"language":73,"meta":74},[71],[76,4951,896],{"__ignoreMap":74},[10,4953,901],{},[60,4955,905],{"id":904},[10,4957,908],{},[68,4959,4961],{"className":4960,"code":912,"language":73,"meta":74},[71],[76,4962,912],{"__ignoreMap":74},[10,4964,917],{},[92,4966,4967,4969,4971,4973,4975,4977],{},[95,4968,922],{},[95,4970,925],{},[95,4972,928],{},[95,4974,931],{},[95,4976,934],{},[95,4978,937],{},[10,4980,940],{},[55,4982,944],{"id":943},[10,4984,947],{},[68,4986,4988],{"className":4987,"code":951,"language":73,"meta":74},[71],[76,4989,951],{"__ignoreMap":74},[10,4991,956],{},[68,4993,4995],{"className":4994,"code":960,"language":73,"meta":74},[71],[76,4996,960],{"__ignoreMap":74},[10,4998,965],{},[68,5000,5002],{"className":5001,"code":969,"language":73,"meta":74},[71],[76,5003,969],{"__ignoreMap":74},[10,5005,974],{},[55,5007,978],{"id":977},[10,5009,981],{},[10,5011,984],{},[92,5013,5014,5016,5018,5020,5022],{},[95,5015,989],{},[95,5017,992],{},[95,5019,995],{},[95,5021,998],{},[95,5023,1001],{},[10,5025,1004],{},[10,5027,1007],{},[29,5029,5030],{},[10,5031,1012],{},[10,5033,1015],{},[10,5035,1018,5036],{},[19,5037,1021],{},[55,5039,1024],{"id":1024},[1026,5041,5042,5047,5052,5057,5062,5067,5072,5077],{},[95,5043,5044,1037],{},[1031,5045,1036],{"href":1033,"rel":5046},[1035],[95,5048,5049,1045],{},[1031,5050,1044],{"href":1042,"rel":5051},[1035],[95,5053,5054,1053],{},[1031,5055,1052],{"href":1050,"rel":5056},[1035],[95,5058,5059,1061],{},[1031,5060,1060],{"href":1058,"rel":5061},[1035],[95,5063,5064,1069],{},[1031,5065,1068],{"href":1066,"rel":5066},[1035],[95,5068,5069,1077],{},[1031,5070,1076],{"href":1074,"rel":5071},[1035],[95,5073,5074,1085],{},[1031,5075,1084],{"href":1082,"rel":5076},[1035],[95,5078,5079,1093],{},[1031,5080,1092],{"href":1090,"rel":5081},[1035],{"title":74,"searchDepth":1095,"depth":1095,"links":5083},[5084,5090,5097,5098,5105,5110,5116,5117,5123,5124,5125],{"id":57,"depth":1095,"text":58,"children":5085},[5086,5087,5088,5089],{"id":62,"depth":1100,"text":63},{"id":83,"depth":1100,"text":84},{"id":138,"depth":1100,"text":139},{"id":177,"depth":1100,"text":178},{"id":216,"depth":1095,"text":217,"children":5091},[5092,5093,5094,5095,5096],{"id":220,"depth":1100,"text":221},{"id":262,"depth":1100,"text":263},{"id":315,"depth":1100,"text":316},{"id":337,"depth":1100,"text":338},{"id":367,"depth":1100,"text":368},{"id":397,"depth":1095,"text":398},{"id":464,"depth":1095,"text":465,"children":5099},[5100,5101,5102,5103,5104],{"id":471,"depth":1100,"text":472},{"id":498,"depth":1100,"text":499},{"id":531,"depth":1100,"text":532},{"id":556,"depth":1100,"text":557},{"id":569,"depth":1100,"text":570},{"id":596,"depth":1095,"text":597,"children":5106},[5107,5108,5109],{"id":603,"depth":1100,"text":604},{"id":624,"depth":1100,"text":625},{"id":645,"depth":1100,"text":646},{"id":666,"depth":1095,"text":667,"children":5111},[5112,5113,5114,5115],{"id":670,"depth":1100,"text":671},{"id":683,"depth":1100,"text":684},{"id":699,"depth":1100,"text":700},{"id":712,"depth":1100,"text":713},{"id":728,"depth":1095,"text":729},{"id":825,"depth":1095,"text":826,"children":5118},[5119,5120,5121,5122],{"id":829,"depth":1100,"text":830},{"id":845,"depth":1100,"text":846},{"id":884,"depth":1100,"text":885},{"id":904,"depth":1100,"text":905},{"id":943,"depth":1095,"text":944},{"id":977,"depth":1095,"text":978},{"id":1024,"depth":1095,"text":1024},{},{"title":5,"description":15},{"id":5129,"title":5130,"body":5131,"commentId":5910,"description":5137,"draft":1141,"extension":1142,"meta":5911,"navigation":1144,"order":5912,"path":5913,"section":1146,"seo":5914,"stem":5915,"updated":1149,"__hash__":5916},"agent\u002Fagent\u002Ffull-stack-wave-digital-employee-developer-workbench-design-decisions.md","全栈化浪潮带来的启示：数字员工与开发工作台的设计抉择",{"type":7,"value":5132,"toc":5882},[5133,5138,5143,5146,5149,5154,5157,5160,5163,5167,5171,5174,5180,5183,5186,5189,5193,5196,5216,5219,5222,5226,5229,5232,5237,5240,5243,5247,5251,5254,5274,5277,5281,5284,5287,5290,5294,5297,5317,5320,5324,5327,5330,5336,5339,5342,5362,5365,5368,5371,5375,5378,5381,5395,5398,5430,5433,5439,5442,5446,5449,5452,5466,5469,5475,5478,5481,5486,5489,5493,5496,5499,5505,5508,5540,5543,5569,5572,5576,5579,5582,5614,5617,5623,5626,5629,5632,5636,5639,5642,5648,5651,5657,5660,5663,5667,5670,5673,5699,5702,5706,5709,5713,5727,5731,5742,5746,5752,5756,5770,5774,5788,5791,5795,5798,5801,5812,5815,5818,5821,5826,5829,5832,5834],[10,5134,5135],{},[13,5136,5137],{},"从产研融合、全栈化与 DRI 责任制出发，分析研发组织为何从职能交接转向端到端结果负责，并讨论数字员工与开发工作台面临的关键设计抉择。",[10,5139,5140],{},[19,5141,5142],{},"系列：从零构建企业级 AI Agent · 第 04 篇",[10,5144,5145],{},"越来越多的组织开始讨论产研融合、全栈化和项目 DRI：产品、前端、后端、测试与运营之间的边界正在变得模糊，一个人或一个小团队被要求对更完整的结果负责。",[10,5147,5148],{},"这类变化很容易被概括成“人人都是产品经理”或“人人都要做全栈”。如果只从岗位名称理解，它似乎是在要求每个人掌握更多技能；但从组织运行方式来看，更深层的变化是：",[29,5150,5151],{},[10,5152,5153],{},"软件研发的责任单位，正在从单一职能和局部任务，转向端到端的产品结果。",[10,5155,5156],{},"与此同时，Coding Agent、生成式 UI、自动测试和智能运维工具降低了跨角色执行的门槛。开发人员可以更快地分析需求、制作原型、补充测试和排查运行问题；产品人员也能借助 AI 完成数据分析、原型验证和简单实现。",[10,5158,5159],{},"那么，角色融合是否意味着专业分工即将消失？全栈是否会成为所有人的必备形态？当我们设计研发数字员工时，应该为每一个传统岗位分别创建一个 Agent，还是围绕端到端交付重新组织能力？开发人员工作台又应该继续按 Bug、代码、流水线等工具模块组织，还是以产品需求为中心？",[10,5161,5162],{},"本文尝试回答这些问题。",[55,5164,5166],{"id":5165},"一角色融合的本质不是一个人做所有工作","一、角色融合的本质不是“一个人做所有工作”",[60,5168,5170],{"id":5169},"_11-传统研发组织以职能分工降低专业门槛","1.1 传统研发组织以职能分工降低专业门槛",[10,5172,5173],{},"传统软件研发经常被组织成一条职能流水线：",[68,5175,5178],{"className":5176,"code":5177,"language":73,"meta":74},[71],"产品定义需求\n→ 设计输出交互\n→ 前端和后端分别实现\n→ 测试负责验收\n→ 运维负责发布\n→ 运营收集反馈\n",[76,5179,5177],{"__ignoreMap":74},[10,5181,5182],{},"这种结构的价值很清楚：每个角色可以在自己的领域形成专业深度，组织也能用相对稳定的岗位和流程管理复杂项目。",[10,5184,5185],{},"但它也产生了大量交接：需求文档交给开发，接口交给前端，代码交给测试，发布包交给运维，用户反馈再从运营回到产品。每一次交接都可能丢失上下文，并引入等待、误解和重复沟通。",[10,5187,5188],{},"当执行成本较高时，专业化带来的收益大于交接成本；当工具和自动化显著降低执行成本后，交接本身就会变得更加突出。",[60,5190,5192],{"id":5191},"_12-全栈化首先是责任范围扩大","1.2 全栈化首先是责任范围扩大",[10,5194,5195],{},"所谓全栈，至少包含三种不同含义：",[1026,5197,5198,5204,5210],{},[95,5199,5200,5203],{},[19,5201,5202],{},"技术全栈","：能够跨前端、后端、数据、基础设施等技术层工作。",[95,5205,5206,5209],{},[19,5207,5208],{},"产品全栈","：能够从用户问题、产品判断一直参与到实现和效果验证。",[95,5211,5212,5215],{},[19,5213,5214],{},"交付全栈","：能够持续推进设计、开发、联调、CR、测试、发布和反馈闭环。",[10,5217,5218],{},"真正影响组织的，往往不是要求每个人成为所有技术领域的专家，而是要求一个人或一个小团队能够覆盖更长的交付链路，并对最终结果保持连续责任。",[10,5220,5221],{},"这也是 DRI 制度的核心价值。DRI 不代表一个人必须亲自完成所有任务，而是意味着项目不能在多个角色之间漂移，必须有人持续掌握目标、进展、风险和决策，并在需要时调用合适的专家与资源。GitLab 对 Engineering DRI 的描述也明确指出，DRI 负责推进和协调复杂工作，但并不等于亲自执行每一个任务。",[60,5223,5225],{"id":5224},"_13-专业分工不会消失","1.3 专业分工不会消失",[10,5227,5228],{},"角色融合不意味着安全、架构、数据库、算法和基础设施等专业能力不再重要。",[10,5230,5231],{},"更可能出现的形态是：",[29,5233,5234],{},[10,5235,5236],{},"广度成为默认能力，深度成为按需调用的专业能力。",[10,5238,5239],{},"一个端到端负责人可以理解并推进完整流程，但在高风险安全变更、复杂数据迁移或重大架构决策中，仍然需要专业人员参与甚至拥有阻断权。",[10,5241,5242],{},"因此，角色融合不是把所有岗位压缩成一个岗位，而是重新安排责任和协作方式：减少不必要的职能交接，同时保留真正有价值的专业判断。",[55,5244,5246],{"id":5245},"二为什么角色融合正在加速","二、为什么角色融合正在加速",[60,5248,5250],{"id":5249},"_21-ai-降低了跨领域执行成本","2.1 AI 降低了跨领域执行成本",[10,5252,5253],{},"过去，一个后端开发想完成产品分析、前端页面和测试自动化，需要跨越多个知识和工具门槛。现在，AI 可以辅助：",[92,5255,5256,5259,5262,5265,5268,5271],{},[95,5257,5258],{},"整理用户反馈和需求背景。",[95,5260,5261],{},"生成交互草图与页面代码。",[95,5263,5264],{},"解释陌生代码和框架。",[95,5266,5267],{},"编写单元测试、接口测试和脚本。",[95,5269,5270],{},"查询日志并归纳异常模式。",[95,5272,5273],{},"生成发布说明和操作文档。",[10,5275,5276],{},"AI 并没有自动赋予使用者专业判断，但显著降低了开始执行和跨越工具边界的成本。原本必须等待另一个岗位完成的工作，一部分可以由当前负责人在 AI 辅助下直接推进。",[60,5278,5280],{"id":5279},"_22-小团队需要更短的反馈回路","2.2 小团队需要更短的反馈回路",[10,5282,5283],{},"软件价值并不在代码合并时产生，而是在功能到达用户并获得验证时产生。",[10,5285,5286],{},"如果需求、开发、测试和反馈分别由不同团队排队处理，即使每个局部环节都很高效，整体周期仍可能很长。DORA 将从想法到客户的工作可见性、客户反馈、小批量交付和团队自主性视为精益产品管理的重要能力；其松耦合团队实践也强调，小团队需要尽量独立地完成修改、测试和发布。",[10,5288,5289],{},"角色融合的目标不是让每个人更忙，而是缩短从问题到结果的反馈回路。",[60,5291,5293],{"id":5292},"_23-工作重心从执行步骤转向组织能力","2.3 工作重心从“执行步骤”转向“组织能力”",[10,5295,5296],{},"当代码生成、测试生成和工具调用逐渐自动化后，人的价值会更多集中在：",[92,5298,5299,5302,5305,5308,5311,5314],{},[95,5300,5301],{},"判断真正需要解决的问题。",[95,5303,5304],{},"建立完整而可靠的上下文。",[95,5306,5307],{},"在多个方案之间进行权衡。",[95,5309,5310],{},"决定风险和授权边界。",[95,5312,5313],{},"验证结果是否满足业务目标。",[95,5315,5316],{},"在不确定情况下组织协作。",[10,5318,5319],{},"软件研发越来越像是对人员、Agent、工具和企业系统的组合与调度。能够连续理解目标并组织这些能力的人，会比只完成某个局部操作的人拥有更大的杠杆。",[55,5321,5323],{"id":5322},"三角色融合不等于取消流程","三、角色融合不等于取消流程",[10,5325,5326],{},"角色边界变得模糊，不代表研发流程失去意义。",[10,5328,5329],{},"一项产品需求仍然可能经历：",[68,5331,5334],{"className":5332,"code":5333,"language":73,"meta":74},[71],"需求规划\n→ 方案设计\n→ 开发\n→ 联调\n→ Code Review\n→ 提测\n→ 测试\n→ 待发布\n→ 发布\n→ 效果观察\n",[76,5335,5333],{"__ignoreMap":74},[10,5337,5338],{},"变化的是，同一个人或同一个小团队可以覆盖更多阶段，不再需要每经过一个阶段就把全部上下文交给另一个职能部门。",[10,5340,5341],{},"流程在这里承担三类职责：",[92,5343,5344,5350,5356],{},[95,5345,5346,5349],{},[19,5347,5348],{},"表达阶段","：当前工作进行到哪里。",[95,5351,5352,5355],{},[19,5353,5354],{},"设置门禁","：进入下一阶段需要什么检查和证据。",[95,5357,5358,5361],{},[19,5359,5360],{},"协调参与者","：当前由谁执行、等待谁反馈、谁拥有最终责任。",[10,5363,5364],{},"Agent 可以在阶段内部动态决定如何完成任务，但不能因此取消组织的权限、质量和审计要求。",[10,5366,5367],{},"例如，Agent 可以自行决定如何完成联调：先检查接口契约、启动依赖服务、构造请求还是查询日志。但“联调是否完成”不应只由模型口头宣布，而应由接口验证结果、关键场景记录和未解决阻断项等证据共同决定。",[10,5369,5370],{},"因此，角色越融合，越需要一套清晰而轻量的工作状态来避免责任和信息重新变得模糊。",[55,5372,5374],{"id":5373},"四研发数字员工不能只是-coding-agent","四、研发数字员工不能只是 Coding Agent",[10,5376,5377],{},"如果研发岗位正在从局部编码走向端到端交付，那么研发数字员工也不能只被定义为“能够修改代码的 Agent”。",[10,5379,5380],{},"Coding Agent 擅长：",[92,5382,5383,5386,5389,5392],{},[95,5384,5385],{},"阅读和修改代码。",[95,5387,5388],{},"执行命令与测试。",[95,5390,5391],{},"分析编译和测试失败。",[95,5393,5394],{},"生成 Diff 与提交说明。",[10,5396,5397],{},"研发数字员工则需要在更长的时间范围内持续工作：",[92,5399,5400,5403,5406,5409,5412,5415,5418,5421,5424,5427],{},[95,5401,5402],{},"理解产品需求和验收标准。",[95,5404,5405],{},"参与技术方案设计。",[95,5407,5408],{},"拆分开发任务。",[95,5410,5411],{},"调用 Coding Agent 完成代码修改。",[95,5413,5414],{},"支持前后端或跨服务联调。",[95,5416,5417],{},"创建 Draft PR\u002FMR 并响应 CR 意见。",[95,5419,5420],{},"处理测试阶段 Bug。",[95,5422,5423],{},"跟踪构建、部署与测试结果。",[95,5425,5426],{},"在飞书群等协作入口接收任务并反馈进展。",[95,5428,5429],{},"在等待外部事件后恢复原任务。",[10,5431,5432],{},"二者的关系更接近员工与专业工具：",[68,5434,5437],{"className":5435,"code":5436,"language":73,"meta":74},[71],"研发数字员工\n├── 持续身份与项目职责\n├── 产品需求上下文\n├── 任务、状态和时间线\n├── 需求与方案能力\n├── 联调、测试与协作能力\n├── 企业系统工具\n└── Coding Agent\n",[76,5438,5436],{"__ignoreMap":74},[10,5440,5441],{},"开发数字员工的第一个闭环可以是处理测试 Bug，但它不能因此被建模成一个“修 Bug 机器人”。Bug 只是产品需求在测试阶段产生的子工作，完整上下文仍然属于产品需求。",[55,5443,5445],{"id":5444},"五不要照搬组织架构创建一组割裂的-agent","五、不要照搬组织架构创建一组割裂的 Agent",[10,5447,5448],{},"一种直观设计是：产品 Agent 负责需求，开发 Agent 负责编码，测试 Agent 负责测试，运维 Agent 负责发布。",[10,5450,5451],{},"这种结构看似对应现有组织，实际上可能把人工流程中的交接问题重新复制到数字系统中：",[92,5453,5454,5457,5460,5463],{},[95,5455,5456],{},"每个 Agent 只持有局部上下文。",[95,5458,5459],{},"状态需要在多个 Agent 之间重复同步。",[95,5461,5462],{},"出现问题时难以判断谁继续负责。",[95,5464,5465],{},"多个 Agent 可能分别优化自己的局部目标。",[10,5467,5468],{},"在项目早期，更适合的形态是一个持续参与需求交付的开发数字员工，在内部按任务调用不同能力：",[68,5470,5473],{"className":5471,"code":5472,"language":73,"meta":74},[71],"开发数字员工\n├── 需求理解能力\n├── 技术方案能力\n├── 编码能力\n├── 联调能力\n├── CR 处理能力\n├── 测试与修复能力\n└── 发布观察能力\n",[76,5474,5472],{"__ignoreMap":74},[10,5476,5477],{},"当安全审查、架构评审、测试设计等领域确实需要独立专业深度时，再引入专业数字员工或专业审查 Agent。",[10,5479,5480],{},"换句话说：",[29,5482,5483],{},[10,5484,5485],{},"先形成一个端到端执行者，再按真实协作需要引入专业协作者。",[10,5487,5488],{},"这与 Anthropic 对 Agent 架构的建议也是一致的：从能够解决问题的简单、可组合方案开始，只在任务复杂度确实需要时增加多 Agent 和复杂编排。",[55,5490,5492],{"id":5491},"六工作台应该从工具集合转向需求驾驶舱","六、工作台应该从“工具集合”转向“需求驾驶舱”",[10,5494,5495],{},"如果工作台仍然按照 Bug、代码、流水线、消息等工具分类组织，开发人员和数字员工仍然需要自己完成上下文拼装。",[10,5497,5498],{},"更合理的中心对象是产品需求：",[68,5500,5503],{"className":5501,"code":5502,"language":73,"meta":74},[71],"ProductRequirement\n├── 目标、范围与验收标准\n├── 技术方案\n├── DevelopmentTask\n├── 联调状态\n├── Commit 与 PR\u002FMR\n├── Bug\n├── 构建、部署和测试结果\n├── 发布状态\n└── 时间线、证据与决策\n",[76,5504,5502],{"__ignoreMap":74},[10,5506,5507],{},"其中：",[92,5509,5510,5516,5522,5528],{},[95,5511,5512,5515],{},[76,5513,5514],{},"ProductRequirement"," 是研发全流程的主对象。",[95,5517,5518,5521],{},[76,5519,5520],{},"DevelopmentTask"," 是需求的实现拆分。",[95,5523,5524,5527],{},[76,5525,5526],{},"Bug"," 是测试阶段发现的缺陷，拥有独立状态机。",[95,5529,5530,4029,5532,4029,5534,5536,5537,5539],{},[76,5531,2379],{},[76,5533,2373],{},[76,5535,2385],{}," 和 ",[76,5538,2391],{}," 记录执行过程、产物、证据和人工检查点。",[10,5541,5542],{},"需求驾驶舱应该直接回答：",[92,5544,5545,5548,5551,5554,5557,5560,5563,5566],{},[95,5546,5547],{},"需求当前处于哪个阶段？",[95,5549,5550],{},"谁是 DRI，谁是当前执行者？",[95,5552,5553],{},"当前阻塞是什么？",[95,5555,5556],{},"下一步应该做什么？",[95,5558,5559],{},"数字员工正在执行什么？",[95,5561,5562],{},"哪些动作需要人工批准？",[95,5564,5565],{},"当前结论由哪些证据支持？",[95,5567,5568],{},"是否存在阻止测试通过或发布的 Bug？",[10,5570,5571],{},"这比再增加一个 AI 输入框更接近真实研发工作的需要。",[55,5573,5575],{"id":5574},"七能力可以融合责任与权限不能混在一起","七、能力可以融合，责任与权限不能混在一起",[10,5577,5578],{},"一个数字员工可以同时拥有需求理解、编码、联调和测试能力，但它是否可以执行某个动作，必须由任务上下文、授权和风险共同决定。",[10,5580,5581],{},"需求中的角色至少应该区分：",[92,5583,5584,5590,5596,5602,5608],{},[95,5585,5586,5589],{},[19,5587,5588],{},"DRI","：对需求交付结果持续负责。",[95,5591,5592,5595],{},[19,5593,5594],{},"Executor","：当前实际执行某项任务的人或数字员工。",[95,5597,5598,5601],{},[19,5599,5600],{},"Reviewer","：提供代码、方案或质量审查。",[95,5603,5604,5607],{},[19,5605,5606],{},"Approver","：对高风险动作进行批准。",[95,5609,5610,5613],{},[19,5611,5612],{},"Specialist","：在安全、架构、数据等领域提供专业判断。",[10,5615,5616],{},"一个典型状态可能是：",[68,5618,5621],{"className":5619,"code":5620,"language":73,"meta":74},[71],"需求 DRI：张三\n当前阶段：联调\n当前执行者：开发数字员工\n专业协作者：支付平台负责人\n待人工处理：确认接口兼容方案\n",[76,5622,5620],{"__ignoreMap":74},[10,5624,5625],{},"在企业采用早期，数字员工可以承担大量执行工作，但最终责任仍应明确落在人类 DRI 或组织角色上。",[10,5627,5628],{},"同样，能力融合不能自动扩大权限。一个研发数字员工可以读需求、分析代码、运行测试和创建 Draft PR，但合并代码、更新关键业务状态、发布生产等动作仍然需要满足门禁或经过审批。",[10,5630,5631],{},"角色融合真正要求的是更细的动作级授权，而不是一个笼统的“允许 Agent 工作”。",[55,5633,5635],{"id":5634},"八workflow-与-agent-应该如何配合","八、Workflow 与 Agent 应该如何配合",[10,5637,5638],{},"角色融合之后，Workflow 的价值不是模拟部门之间的工单流转，而是为端到端工作提供可靠底座。",[10,5640,5641],{},"可以把两者的边界概括为：",[68,5643,5646],{"className":5644,"code":5645,"language":73,"meta":74},[71],"确定性流程\n├── 阶段与合法状态\n├── 权限与审批\n├── 进入条件和质量门禁\n├── 等待、重试和恢复\n└── 证据与审计\n\nAgent\n├── 理解需求和反馈\n├── 规划阶段内任务\n├── 选择工具\n├── 分析异常\n├── 生成方案与代码\n└── 根据结果调整行动\n",[76,5647,5645],{"__ignoreMap":74},[10,5649,5650],{},"稳定的研发主流程仍然可以是：",[68,5652,5655],{"className":5653,"code":5654,"language":73,"meta":74},[71],"方案设计 → 开发 → 联调 → CR → 提测 → 测试 → 发布\n",[76,5656,5654],{"__ignoreMap":74},[10,5658,5659],{},"Agent 在每个阶段内部处理无法预先穷举的具体问题；确定性程序负责判断是否满足进入下一阶段的条件。",[10,5661,5662],{},"这使工作台既不会退化成僵硬的流程画布，也不会把所有真实副作用交给不受约束的模型。",[55,5664,5666],{"id":5665},"九如何衡量研发数字员工的价值","九、如何衡量研发数字员工的价值",[10,5668,5669],{},"如果数字员工的目标是端到端交付，就不能只用代码生成量、模型调用次数或自动修改文件数衡量价值。",[10,5671,5672],{},"更有意义的指标包括：",[92,5674,5675,5678,5681,5684,5687,5690,5693,5696],{},[95,5676,5677],{},"需求从开始到发布的周期是否缩短。",[95,5679,5680],{},"等待和跨角色交接时间是否减少。",[95,5682,5683],{},"联调和 CR 阶段的阻塞是否更早暴露。",[95,5685,5686],{},"Bug 从发现到已修复、验证和关闭的时间是否缩短。",[95,5688,5689],{},"变更失败率和返工是否增加。",[95,5691,5692],{},"数字员工有多少行动需要人工接管。",[95,5694,5695],{},"人工接管是否发生在真正需要判断的节点。",[95,5697,5698],{},"需求状态、风险和证据是否更加透明。",[10,5700,5701],{},"角色融合的目的不是让一个人承担更多孤立任务，而是提高价值流动效率。数字员工也应该以相同标准接受评估。",[55,5703,5705],{"id":5704},"十从第一个闭环走向企业数字员工","十、从第一个闭环走向企业数字员工",[10,5707,5708],{},"研发数字员工可以按照以下路径逐步演进：",[60,5710,5712],{"id":5711},"第一阶段建立正确的工作模型","第一阶段：建立正确的工作模型",[92,5714,5715,5718,5721,5724],{},[95,5716,5717],{},"以产品需求作为主对象。",[95,5719,5720],{},"区分开发任务与 Bug。",[95,5722,5723],{},"明确设计、开发、联调、CR、测试和发布阶段。",[95,5725,5726],{},"建立 DRI、执行者、审查者和审批者边界。",[60,5728,5730],{"id":5729},"第二阶段连接真实研发系统","第二阶段：连接真实研发系统",[92,5732,5733,5736,5739],{},[95,5734,5735],{},"读取云效项目和测试 Bug。",[95,5737,5738],{},"关联需求、代码仓库和测试环境。",[95,5740,5741],{},"汇聚 PR、CI、部署和回归证据。",[60,5743,5745],{"id":5744},"第三阶段完成第一个主动式闭环","第三阶段：完成第一个主动式闭环",[68,5747,5750],{"className":5748,"code":5749,"language":73,"meta":74},[71],"测试 Bug\n→ 分析上下文\n→ 修改代码\n→ 自测与联调\n→ 创建 Draft PR\n→ 跟踪 CR、CI 和部署\n→ 标记已修复\n→ 等待回归结果\n",[76,5751,5749],{"__ignoreMap":74},[60,5753,5755],{"id":5754},"第四阶段进入团队协作","第四阶段：进入团队协作",[92,5757,5758,5761,5764,5767],{},[95,5759,5760],{},"加入飞书项目群。",[95,5762,5763],{},"接收任务、Bug 反馈和补充信息。",[95,5765,5766],{},"主动反馈进度、风险和等待事项。",[95,5768,5769],{},"在外部事件到达后恢复长期任务。",[60,5771,5773],{"id":5772},"第五阶段扩展端到端能力","第五阶段：扩展端到端能力",[92,5775,5776,5779,5782,5785],{},[95,5777,5778],{},"需求分析和验收标准生成。",[95,5780,5781],{},"技术方案设计和任务拆分。",[95,5783,5784],{},"发布观察和线上问题处理。",[95,5786,5787],{},"根据用户和运营反馈推动下一轮迭代。",[10,5789,5790],{},"最终目标不是制造一个无边界的通用 Agent，而是形成一个围绕产品需求持续工作、能够跨越研发多个阶段，并在权限和流程约束下交付结果的企业数字员工。",[55,5792,5794],{"id":5793},"十一总结围绕结果重新组织人agent-与工具","十一、总结：围绕结果重新组织人、Agent 与工具",[10,5796,5797],{},"产研融合和全栈化并不意味着每个人都要成为所有领域的专家，也不意味着传统专业能力失去价值。",[10,5799,5800],{},"它们反映的是三个更深层的变化：",[1026,5802,5803,5806,5809],{},[95,5804,5805],{},"责任从局部职能转向端到端结果。",[95,5807,5808],{},"AI 降低了跨领域执行和工具切换的成本。",[95,5810,5811],{},"专业能力从固定交接节点，逐渐变成可以按需调用的协作资源。",[10,5813,5814],{},"对于研发数字员工，这意味着它不能只是 Coding Agent，也不应被拆成一组互相交接的岗位机器人。它需要围绕产品需求持续工作，在设计、开发、联调、CR、测试和发布之间保持上下文，并在需要时调用专业工具和专业协作者。",[10,5816,5817],{},"对于开发人员工作台，这意味着系统中心不能是聊天会话，也不能只是 Bug、代码和流水线的工具集合，而应该是产品需求及其完整交付上下文。",[10,5819,5820],{},"更准确的目标是：",[29,5822,5823],{},[10,5824,5825],{},"用产品需求承载端到端上下文，用 Workflow 表达阶段、门禁和责任，用 Agent 处理阶段内的不确定性，用专业工具完成具体执行，并让人类 DRI 对最终结果保持清晰责任。",[10,5827,5828],{},"角色融合带来的真正机会，不是让一个人或一个 Agent 做完所有事情，而是重新围绕结果组织人、数字员工、流程与工具。",[10,5830,5831],{},"下一篇将回到系统实现，讨论如何把产品需求、开发任务、Bug、联调阶段和统一工作引用落成可演进的领域模型。",[55,5833,1024],{"id":1024},[1026,5835,5836,5844,5852,5860,5868,5876],{},[95,5837,5838,5843],{},[1031,5839,5842],{"href":5840,"rel":5841},"https:\u002F\u002Fhandbook.gitlab.com\u002Fhandbook\u002Fpeople-group\u002Fdirectly-responsible-individuals\u002F",[1035],"GitLab Handbook：Directly Responsible Individuals"," — DRI 的责任、决策权以及与协作者之间的关系。",[95,5845,5846,5851],{},[1031,5847,5850],{"href":5848,"rel":5849},"https:\u002F\u002Fhandbook.gitlab.com\u002Fhandbook\u002Fengineering\u002Fdevelopment\u002Fgrowth\u002Fengineering_dri\u002F",[1035],"GitLab Handbook：Engineering DRI for Large-Scale Initiatives"," — Engineering DRI 如何拆解工作、跟踪进度、管理风险并调用专业协作者。",[95,5853,5854,5859],{},[1031,5855,5858],{"href":5856,"rel":5857},"https:\u002F\u002Fdora.dev\u002Fcapabilities\u002Fwork-visibility-in-value-stream\u002F",[1035],"DORA：Visibility of work in the value stream"," — 从业务想法到客户价值的工作可见性。",[95,5861,5862,5867],{},[1031,5863,5866],{"href":5864,"rel":5865},"https:\u002F\u002Fdora.dev\u002Fcapabilities\u002Floosely-coupled-teams\u002F",[1035],"DORA：Loosely coupled teams"," — 团队自主交付、技术架构与组织结构之间的关系。",[95,5869,5870,5875],{},[1031,5871,5874],{"href":5872,"rel":5873},"https:\u002F\u002Fdora.dev\u002Fcapabilities\u002Fworking-in-small-batches\u002F",[1035],"DORA：Working in small batches"," — 跨职能团队、小批量工作与交付效率。",[95,5877,5878,5881],{},[1031,5879,1036],{"href":1033,"rel":5880},[1035]," — Workflow、Agent、工具使用和从简单架构开始的设计原则。",{"title":74,"searchDepth":1095,"depth":1095,"links":5883},[5884,5889,5894,5895,5896,5897,5898,5899,5900,5901,5908,5909],{"id":5165,"depth":1095,"text":5166,"children":5885},[5886,5887,5888],{"id":5169,"depth":1100,"text":5170},{"id":5191,"depth":1100,"text":5192},{"id":5224,"depth":1100,"text":5225},{"id":5245,"depth":1095,"text":5246,"children":5890},[5891,5892,5893],{"id":5249,"depth":1100,"text":5250},{"id":5279,"depth":1100,"text":5280},{"id":5292,"depth":1100,"text":5293},{"id":5322,"depth":1095,"text":5323},{"id":5373,"depth":1095,"text":5374},{"id":5444,"depth":1095,"text":5445},{"id":5491,"depth":1095,"text":5492},{"id":5574,"depth":1095,"text":5575},{"id":5634,"depth":1095,"text":5635},{"id":5665,"depth":1095,"text":5666},{"id":5704,"depth":1095,"text":5705,"children":5902},[5903,5904,5905,5906,5907],{"id":5711,"depth":1100,"text":5712},{"id":5729,"depth":1100,"text":5730},{"id":5744,"depth":1100,"text":5745},{"id":5754,"depth":1100,"text":5755},{"id":5772,"depth":1100,"text":5773},{"id":5793,"depth":1095,"text":5794},{"id":1024,"depth":1095,"text":1024},"wiki:agent:full-stack-wave-digital-employee-developer-workbench-design-decisions",{},4,"\u002Fagent\u002Ffull-stack-wave-digital-employee-developer-workbench-design-decisions",{"title":5130,"description":5137},"agent\u002Ffull-stack-wave-digital-employee-developer-workbench-design-decisions","LsjheoPaXG1DnA-PsHOj5IN-IzeVYqy7uqRjPf5wrxI",1794384927375]