您公司中谁是智能代理的负责人：六项职责及其承担者
贵公司里谁负责管理人工智能代理？鉴于SR 26-2对人工智能代理、六种责任角色、如何从现有团队中调配人员以及日常运营均未作出明确规定。
来源: Who Owns What When Your Company Deploys an AI Agent: Six Responsibilities, and Which Teams Hold Them
代理型人工智能指的是能够自行决定行动顺序并调用相关工具的软件，而非遵循固定脚本运行。当这类软件在企业内部使用时，一个简单的问题随之出现：应由哪个人负责？
监管机构尚未对此给出明确答案。在2026年4月17日发出的编号为SR 26-2的联合函件中，联邦储备系统取代了自2011年以来银行所遵循的SR 11-7模型风险管理指南，同时废除了货币监理局此前发布的相关公告。该函件还指出，生成式人工智能与代理型人工智能不在这些指南的覆盖范围内。此外，旧指南中详细阐述的“模型所有者”概念在新的指南中完全不见踪影。
五个月前，新加坡选择了另一条路径。新加坡金融管理局拟定的人工智能风险管理指南已于2026年1月结束征求意见，截至本文撰写时仍未出台最终版本，但这些指南将人工智能代理明确纳入监管范围。它们警告称，拥有系统访问权限的代理可能会做出与业务目标或客户利益相悖的行为，并要求在将任何高风险系统投入运行之前进行独立验证，即由非系统开发人员来进行审查。该文件目前还不是法律，且仅对某一司法管辖区内的持牌机构具有约束力。
两份文件均未明确说明在智能体运行后，公司内部应由谁对其负责，而这一空白无法等待监管机构来填补。能够自主行动的软件需要有一个行为边界，即划分出它可自行完成的任务与需要人工干预的任务的界限。划定这一界限属于技术问题；而确定谁对该界限负责则属于组织管理范畴，现有文件并未对此作出规定。接下来的内容涵盖了智能体可能执行的各项操作或出现的错误，并针对每一种情况指明了应承担责任的人选。它探讨了由谁进行最终审批、如何从现有团队中分配相应职责、智能体上线后的运行管理方式，以及开发者需要掌握的知识。相关依据包括监管文件、2024年以后发表的研究报告，以及那些为特定主张背书的企业。
六项职责，六位负责人
在实际项目中，一个任务会产生六项职责，每项职责都需要一名负责到底的负责人。可以这样理解职责结构：负责人对最终结果负责，执行者负责完成具体工作，而咨询者仅提供意见，没有最终决策权。
- 业务与领域方面。业务负责人以及领域专家。业务负责人对用例负责，而其中一位专家同时担任标准制定者，即那些对领域足够熟悉、能够判断什么是正确做法的人。
- 产品与架构方面。架构师、产品经理以及对话设计师。
内部审计不在该列表之中，因为SR 26-2规定其通常不会重复模型风险管理的相关工作。下文提到的几家公司（凯撒永久医疗集团、汤森路透、摩根士丹利）使用的是起草和检索工具而非完全自主的智能体，因此它们是最接近的公开案例。
企业所有者：审批智能体的操作权限
这种审批涵盖操作范围、金额阈值以及智能体不得接触的客户群体，具体标准会根据风险等级进行划分，与新加坡的提案类似。它还涉及系统的资金投入及最终的退役事宜。根据美国货币监理署2021年的审查手册，银行在企业内部设有承担此职责的岗位，这一做法有部分先例可循；不过并非所有银行都如此，而2026年的修订则取消了这一岗位，也未设立替代角色。
实际考量比先例更具说服力。在那些审批决定中，无论是设定阈值、排除某些客户群体还是确定终止日期，都是在收益或服务与风险之间进行权衡。唯有对最终结果负责的人才能做出这种权衡并为此负责。担任决策者的人必须同时拥有预算决策权和终止权，而只有企业主才具备这两项权力：风险无法资助的项目就无法推进，而工程团队则能完成那些风险无法阻止的任务。如果将决策权交给工程团队，他们就会自行决定项目范围；而若交给风险管控部门，则没人会对收益方面负责。新加坡的表述也指向同一方向，因为它将损害程度与业务目标及客户利益相联系，而只有企业才能界定这些目标。香港的指导原则则将责任归于董事会。
架构师：掌控设计
设计存在于智能系统停止运作、由人类介入的节点上。它包括智能系统遵循的流程、向人类移交工作的节点，以及防止系统继续运行的权限设置。后两者共同构成了具体的行为边界。有两家公司将移交节点设置在了同一位置：凯撒永久医疗集团的医生会在文档进入病历系统之前对其进行编辑；而根据摩根士丹利的公告，其Debrief工具也会让顾问在将会议总结录入客户数据库之前进行修改。工程师或供应商可以构建权限模型和界面，但架构师依然掌握主导权，因为流程的定位属于设计决策，无论由谁编写代码都必须遵循。
标准制定者：编写评估准则
评分标准是一份列明正确答案应包含要素的清单。在汤森路透，合伙人级别的资深律师曾花费数月时间为某检索应用制定评分标准。他们总结称，优秀的答案需具备15个必要要素，而看似合理的答案则只有9个。唯有律师才能区分15个与9个要素，这也意味着制定评分标准需要领域专家投入大量时间，而且必须由专人负责，因为多人评分时标准会发生变化。一篇关于验证大型语言模型验证工具的研究论文发现，一旦开始评分，标准就会出现偏差；Shreya Shankar和Aditya Parameswaran针对使用数据查询工具的人所进行的研究也得出了相同结论，指出验证工作最终会落在用户身上。
制定标准与依据标准进行衡量是两件不同的事情。衡量工作，即日常的评估与错误分析，由工程师和数据科学家负责。他们编写评估规则，构建测试框架（用于通过代理程序运行测试用例并评估结果），并分析出现的故障。随后，验证人员会检查代码覆盖率及评估规则的准确性，而无需重新运行开发团队的测试。
运营：确保系统持续运行
系统上线后，工作内容包括值班期间的代码覆盖率监控、警报分类处理、系统关闭与恢复、重新运行回归测试套件（每次代码变更后都需要重新运行的测试用例），以及监控系统使用情况和成本。由于某些警报涉及业务决策，因此会有业务人员参与值班轮班。调度安排、警报严重程度分级以及问题上报流程则由作为工程师的运营负责人负责。
验证器：发布前的检查
验证器的审查包含三个部分。它会检测是否存在注入式攻击（即在智能体读取的资料中植入恶意指令）以及未经授权的工具调用。它还会检查哪些个人数据会出现在智能体的操作日志中，即其逐步行动的记录。同时，它还会监督那些负责审批智能体行为的人。
供应商经理：掌控合同
只有当公司进行采购时，该席位才会出现。此时供应商会构建系统的一部分，运行相关操作，并生成验证者必须审查的凭证，而责任归属依然保持不变。与此同时，其他所有所有者都依赖于只有合同才能提供的东西。验证者需要审计权限；运营团队需要提前获知模型变更信息，因为这会触发回归测试。标准所有者需要能够导出追踪记录和数据的手段，否则公司的评估就无从进行。业务所有者则需要退出条款，否则关闭系统就会变成一场谈判而非一个决定。供应商经理无需亲自执行这四项工作，就能确保这四项内容得到落实。采购部门仅在范围和验收方面被征求意见，但对这两方面均无需承担责任。
这六个角色中的三个——负责明确使用场景、判定何为正确结果以及独立检查结果——都是供应商的实现团队无法独自完成的。为每个角色指定负责人，正是监管文件中未提及的环节。
从现有团队中调配人员
这些角色由现有人员担任，且顺序很重要，因为每个角色都依赖于前一个角色。
首先要确定业务负责人；在找到合适人选之前，项目必须暂停。该负责人负责掌控预算、流程以及关闭系统的权限，还会首先为风险分配等级并批准代理人员可执行的操作。工程人才无法替代这一角色，因为没有其他人能承担其所需的权衡责任。
接下来是架构师。理想情况下，这个人应当足够了解业务流程和系统，能够明确界定自动化流程的终点与人工干预的起点。有合适人选时，该职位就由此人担任；若找不到合适人选，外部人员也可启动相关工作，但公司仍需指定一名内部负责人，因为即便工作在别处进行，该职位也不能空缺。
第三类是标准制定者，决定性因素在于该领域专家是否有实际时间投入。如果时间得到保障，专家就会亲自撰写评估标准，就像汤森路透的律师们所做的那样。若没有足够时间，产品和设计人员会先起草草案供专家审批，这样一来标准就会逐渐偏离正轨，因为那些知道优秀答案应具备什么特征的人并非负责将其写下来的人。杰米·戴蒙在致股东的信中指出了一个普遍规律：由多人分头承担的工作永远无法完成，而这项使命需要一个全身心投入的团队来推进。
在对该系统的评估员功能进行校准并监测其偏差时，若公司设有数据或分析团队，相关工作应交由该团队处理；否则，则需由开发团队中的指定成员抽出专门时间来完成。案例表明，一旦模型由供应商提供，数据科学团队的角色就会发生变化——建模与微调工作转由供应商负责，因此不能再将数据科学工作完全归为人工智能团队的事务。此时剩下的任务就是持续进行校准与偏差监测，同时还需为团队不断开发的信用、欺诈、定价及预测模型新增一项职责：在允许任何系统将这些模型作为工具使用之前，必须明确说明每个模型的适用人群。保险公司和医院可能也会面临关于自身模型的类似问题，但此处所分析的所有资料均未涉及这些内容。
第四是验证环节，决定性因素在于何时纳入合规性考量。合规团队可以从一开始就提供风险定义，据报道Chime的合规团队就是如此做的；或者仅在发布阶段进行审查，在这种情况下，根据新加坡的草案要求，高风险用例在部署前仍需独立验证。对银行而言，现有的模型风险管控机制似乎是最简便的途径，因为SR 26-2并未对相关机构作出强制规定，由各机构自行决定。不过，2024年及以后的相关报道中并未出现有银行采取该措施的案例。
第五是运营环节，决定性因素在于系统上线后由谁来监控。下一节将详细介绍这一点。
所有使用场景都有两个共通要素。首先是对所有智能体访问模型时必经的通道——即网关，在此会进行身份验证并记录调用日志，该网关由运营负责人管理。Wealthsimple表示大约80%的LLM流量都通过其网关传输，但其余流量的管理方式尚不明确。其次是对性能的衡量机制，也就是评估工具和评判标准，这部分由数据科学团队和分析团队共同负责，因为若两个团队使用不同的评估工具进行自我评分，得出的数据将无法相互比较。其余部分，包括具体使用场景、评估细则、标准制定者以及该场景在轮换机制中的位置，则由负责运营该场景的业务部门掌控。
这些岗位大多只是扩展现有工作，并不会创造新的职位。已经负责损益管理的业务负责人负责审批工作范围，领域专家则在其已有的知识体系中补充评估标准，工程师则负责操作相关工具。数据科学团队原本就在监控自身模型的性能衰减，现在还将这一监控范围扩展到代理系统上。合规团队则将风险定义纳入其原有的审查流程中。并没有新增招聘的需求，只有验证员这一岗位无法被扩展，因为构建工作结束之处也正是该岗位工作的起点。
日常代理系统运营
系统上线后，会有六项职责贯穿其整个生命周期。运营负责人负责其中四项，标准管理负责人负责一项，验证员负责一项，每项职责都需要指定具体负责人并设定响应时间。
警报分级处理由运营团队负责，由业务人员轮值处理。警报并非千篇一律：权限错误、服务中断以及被错误拒付的索赔都需要不同的判断方式，其中后者属于业务决策范畴。新加坡的草案与欧盟的《人工智能法案》均要求建立此类升级处理流程。
关闭操作需经企业主批准后由运营团队分四个阶段执行：立即停止、技术恢复、业务纠错以及允许重新启动。欧盟《人工智能法案》规定，高风险系统的监管者必须能够通过停止按钮或类似程序使其进入安全状态。设计按钮的人并不一定是决定按下按钮的人。关闭聊天窗口不会取消已排队的支付或通知，而业务纠错也没有代码回滚的对应机制。因此，决定是否停止属于业务决策范畴，而实际执行则属于运营任务。
模型变更后的回归测试是数据科学团队、工程团队与业务部门共同参与的工作，最终由验证人员确认后才能发布。摩根士丹利的Assistant就是一个有据可查的例子：它虽然基于OpenAI的模型运行，但该银行却建立了自己的评估框架。顾问和提示词工程师每天会一起对回归测试套件进行评分，而供应商既不提供评分标准，也不说明其依据。这项服务的来源是OpenAI，它们通过展示客户案例来获得收益，且该服务涉及检索应用。整个流程的启动源于供应商发出的变更通知，而这一通知必须由供应商经理来确保落实。
使用情况与成本由运营部门负责统计，合适的计量单位是已完成的任务。重试、评估和返工都属于同一任务，而一次模型调用仅是其中的一部分，因此仅按每次调用定价只能反映成本的一部分情况。
将生产过程中的故障反馈给评估系统是标准制定者的持续职责。在Arize公司重新发布的一篇演讲中，这家公司的客户包括Uber，Uber的对话设计师表示，评估系统及其数据集会每周更新一次，因为使用过时的数据集得到的信号还不如没有信号。这实际上是由设计师承担了原本应由工程师和数据科学家完成的工作。据报道，Chime的合规信号会在几小时内通过事后进行的离线评估传递给评估系统。
监控审批者是验证人员持续需要完成的工作。Anthropic称，其编码智能体的权限请求中有约93%被批准，这一比例之高足以表明这只是形式上的审批而非真正的核查。由于该智能体属于编码类而非业务流程类，因此此处仅能说明存在风险而无法给出具体数值。NIST的生成式AI评估框架虽为自愿性质，但建议记录每次有人绕过系统输出结果的情景，这其实与从另一角度进行的核查是相同的。
这些工作永远没有终点，也没有任何公开账号会披露相关人员的工作时长。任务轮换、回归测试以及成本跟踪等服务都可以从外部购买，这将是后续需要讨论的问题。
团队必须掌握的知识以及标准的高低
培训会引发三个问题：团队中的每个人必须具备什么能力，哪些领域仍需要专家，以及何种质量标准才算合格。
无论职位如何，都有四项技能是所有人都需要掌握的：
- 亲自查看追踪数据与评估结果，而非依赖他人的总结
- 从结果的整体分布角度进行推理，而非仅关注个别案例
- 根据最终成果来判断工作质量，而非听信执行者自称的完成情况
- 将任务描述得足够清晰以便委派他人执行，随后监督执行结果
高盛的首席信息官马可·阿尔根蒂提到了最后这一系列要求。用他的话来说，领导者必须掌握三项管理技能：明确描述任务、将任务委派给人工智能代理，并监督执行结果。
一半的评估工作仍需要专家来完成。评估与错误分析的循环，以及日常对输出结果进行评分并追溯故障根源的工作，可分为常规部分与偶尔出现的部分。常规部分包括编写评估工具、构建相关框架以及分析每日出现的故障。这需要工程技能和统计知识，雇主们也越来越倾向于将这类工作统称为“AI工程师”。DeepLearning.AI的技能地图通过招聘信息与面试内容来描述这一职位，不过该平台的出版商恰恰在销售那些招聘信息中所要求的课程。偶尔出现的部分则是用人工标注来校准评估工具并检测数据偏差，这类工作更适合数据科学家处理，主要在需要重新评估时才会用到。 非科技企业明智的做法是培养软件工程师来承担人工智能工程师的工作，同时保留数据科学领域的人才用于校准以及支持验证器的审核工作。目前还没有研究对比过这两种配置，而“技能地图”报告仅反映了雇主的需求。
该阈值旨在捕捉那些工具始终无法识别的故障类型，这一职责由标准制定者与验证人员承担。在2026年的一项研究中，教授付费评估课程的Antaripa Saha与Hamel Husain在包含39个人工标记故障的100个生产日志上测试了六种自动化审查系统。表现最好的系统能找到87%的标记故障，而那些未被识别的故障具有系统性，有一类故障能逃过所有系统的检测。此外，这些系统还标记出了人工审查员遗漏的故障，因此这些分数并不能用于排名，相关数据也仅包含一位专家的标记结果。这项研究确实表明了哪些领域仍需要人类参与：负责定义何为故障的标准制定者，以及通过覆盖率检查来发现工具遗漏问题的验证人员。
这种能力是通过向人们展示失败案例并依靠定期审查来建立的。拥有相同付费课程兴趣的Husain和Shankar将评分工作分为工程师和产品经理负责。工程师负责发现技术问题，如数据检索故障和工具错误，而产品经理则负责识别产品缺陷，比如用户期望未得到满足的情况。日常评分由单一决策者处理，这与验证者的独立审查属于不同职责。为获得认同，他们建议不要只展示评估结果，而是让同事们看到他们查看数据后所得出的内容。新加坡的草案还增加了另一项要求：必须定期重新评估这一能力本身。
这些证据能够支持什么，又无法支持什么
每项监管条文及每起具体案例都有其来源，但范围限制同样重要。监管规定明确了相关要求，而SR 26-2将代理型人工智能排除在其适用范围之外。这些研究依赖于数据查询用户、一个数据集中的39起故障案例以及少量定性样本。Kaiser、汤森路透和摩根士丹利的辅助工具仅属于检索或起草工具，并非能够独立执行多步骤操作的代理。目前还没有非科技企业公开过其代理团队的名单，那些被提及的企业也只是自愿公开信息，因此那些悄无声息失败的项目并未被纳入样本。这类企业大多不会纠结于是否购买代理平台，而是会选择大型云服务提供商后再继续发展。更艰难的抉择在于是否需要外部帮助，比如咨询服务、人员补充或驻场工程师，以及合作结束后该如何处理后续事宜。 所有六个职位仍由内部人员担任，可购买的只是执行服务而已。
美联储在4月将模型所有者从相关指导文件中移除，而新加坡在五个月前就提议，应由开发团队之外的人员对拥有系统访问权限的代理进行审核。这两份文件均未明确指出公司中谁应对该代理负责。一家公司需要指定六位负责人，首当其冲的是业务所有者，他负责批准代理的权限、承担相关费用，并能随时终止其操作。尽管监管机构不再明确描述这一角色，但它绝不能空缺，因为正是这一批准决定了其他所有人工作的范围。马可·阿尔根蒂的警告依然适用：若无法监督代理却将其工作委派出去，必将引发灾难，因此人们需要建立新的质量管控意识与责任意识。
相关阅读
- 您的智能体图谱应使用 YAML：在启动时编译包含 17 个智能体的 LangGraph —— 小型运行时如何将一个 YAML 规范编译为 LangGraph StateGraph：生成的状态、importlib 插件、标签路由器、自适应调用以及会话级别的节点替换。
- Gemini Spark 详解：任务、技能、调度、安全性与定价 —— Google 的全天候运行 Gemini Spark 智能体在 Gmail、日历和文档中的功能，其安全机制的运作方式、成本、被限制使用的场景以及适合采用它的群体。