Jira 中的人工智能支持人员约束机制与安全管控
护栏可借助智能体工作流建立信任，从而让您规模化采用人工智能。有效的护栏会内嵌至您的工作流中，由系统强制执行，而非依靠支持人员去执行。
在 Jira 中，该系统就是您团队日常开展工作所使用的平台。Jira 通过权限限定支持人员的访问范围；设置检查点，由人工对工作流流转节点作出判断；同时完整记录支持人员针对工作项执行的每一项操作。Teamwork Graph 为支持人员提供开展工作所需的正确上下文信息。
本指南介绍支持人员护栏所要化解的各类风险，以及如何在 Jira 中落实这些护栏，以便您能安全、负责任地规模化部署人工智能，从而让您可以在不失控的前提下，赋予支持人员在团队各项工作（从维持业务运转的日常任务到高价值项目）中更高的自主执行权限。这种大规模的自主运行能力，依托您借助团队现有的工作流、权限和规则在 Jira 内设置的四项护栏：
限定访问范围。依托 Jira 现有权限，设置支持人员能够访问的数据、可使用的工具以及允许执行操作的范围。
限制高风险调用。利用工作流转，要求高影响工作落地之前必须经过人工审批。
审查输出成果。在成果发布前，通过常规的拉取请求审查流程检查支持人员生成的内容。
留存记录。支持人员执行的每一步操作都会记入工作项历史记录，并关联对应的审批人。
什么是智能体工程中的护栏？
支持人员护栏是一套管控机制，用来保证人工智能支持人员的工作安全、符合预期且留存记录：包括它可访问的内容、人工介入的节点，以及所有操作的记录。护栏由支持人员所处的系统强制执行，而非依靠支持人员自觉遵守。
您无法仅通过下达行为指令就保障支持人员安全，因为指令有可能被遗忘、误读或是被绕过。真正的护栏独立于支持人员之上，部署在它的环境中；无论支持人员收到何种指示，这条边界都不会被突破。这和您团队现行的原理一致：由系统决定可执行范围，而非依靠要求执行者遵守规则。
在实践中，支持人员护栏涵盖以下几个相关领域：
访问权限与范围。支持人员可访问的数据、可使用的工具，以及可以执行操作的位置。
限定任务。支持人员可全权负责的工作，以及必须由人类承接的工作。
人工介入审批。工作推进前，交由人员审查或审批的检查节点。
输出审查。支持人员生成内容在交付前进行验证。
问责与审核。支持人员执行的操作、原因以及审批人的相关记录。
治理。随着支持人员使用规模扩大，确保这一切保持一致的常规管控措施。
以上要素共同构建起人们对智能体工作流的信任。团队可以在不失管控的前提下赋予支持人员更多职责，因为结果仍由人类承担责任。
为什么人工智能支持人员需要护栏？
支持人员具备执行操作的能力。与仅能给出建议的聊天机器人不同，支持人员可以修改代码、转移工作，并在各类工具中触发实际操作。正是这种自主能力让它们具备实用价值，同时这也是其需要护栏的原因：支持人员可独立完成的事情越多，就越有必要保证其工作方向合规统一、经过审查且权责可追溯。
护栏所要应对的核心风险，以及必须保留人工判断的场景：
目标偏差：支持人员朝着错误的方向优化，或是偏离原定任务。
低质量或错误输出：看似已经完成，实则不达要求的工作，其中包含产生幻觉的代码或虚假事实。
访问权限范围过宽：支持人员越权访问受限数据或系统。
未经审查的不可逆操作：无法彻底撤销的高影响变更，例如发布至生产环境或删除数据；此类操作生效前必须设置人工检查节点。
缺乏问责制或透明度：若无记录，便无人能够查看支持人员执行了哪些操作，或是何人予以审批。
成本失控：支持人员对令牌与算力的消耗具有不可预测性，因此和其他所有资源一样，开销需要设置限额。
护栏唯有由系统强制执行才能生效，而非依靠支持人员自觉遵守。仅仅告知支持人员哪些事情不可做，并不能算作护栏，因为即便收到相关约束指令，支持人员仍有可能在您不知情的情况下执行该操作。真正的护栏要位于支持人员之上，部署在其运行的环境之中，以便杜绝违规操作发生，而不仅仅是加以劝阻。
正因如此，护栏是实现支持人员自主能力的先决条件，而非对其施加的限制。信任这套边界的团队，可以在减少人工监管的前提下，赋予支持人员更多职责。而做不到这一点的团队，将会丧失引入支持人员原本想要获得的效率提升。
如何在 Jira 中安全管控人工智能支持人员？
倘若护栏必须部署在支持人员所在系统的上层，那么该系统便是关键；对于工程工作而言，这个系统就是 Jira。当支持人员在 Atlassian System of Work 内运行时，它访问您的数据与工作项所依托的，正是团队已在使用的同一套 Jira 权限，以及您现有的工作流以及审核追踪记录。支持人员在自身运行环境内能够执行的操作，依旧由支持人员管控。因此，Jira 负责管控工作内容的访问权限，而支持人员级别的权限则管控它所运行的工具。
单独来看，编码支持人员仅能管控其自身行为。而 Jira 管控着工作本身，因此护栏可以在一处统一作用于所有支持人员，并且您能够查看每一项护栏所应对的风险。
工作流便是大部分强制管控落地之处。用于在人员之间分派工作的状态、流转与规则，同样可将任务分派给支持人员，决定支持人员可执行哪些流转，并且暂缓高影响变更，等待审批。
访问权限：您可在 Jira 内管控的内容
第一项管控是范围：支持人员可处理哪些数据、工具以及项目。这便是防范越权访问的护栏。您在 Jira 中配置该项权限的方式，和为团队伙伴配置权限完全一致，操作方式熟悉易懂，并且可由您灵活调整。
在 Jira 中的工作原理：您选定支持人员执行操作时所使用的身份。默认情况下，支持人员会以背后操作人员的身份执行操作，仅能够访问该人员有权查看的数据、项目以及工作项。您也可以为支持人员配置独立帐户与权限，使其访问权限不再依附于任何个人。管理员管控支持人员的启用状态以及可用范围。支持人员调用自身配套工具所能执行的操作，由支持人员本身管控，不受 Jira 约束。您可以放开宽泛权限或是收紧访问边界，并随着信任程度的提升逐步扩大权限范围。
可供您调整的管控项。这些就是您早已用于人员管理的权限控制手段：权限方案与项目角色决定支持人员在一个项目内可执行的操作，事务安全则限定它能够查看哪些特定工作项。收紧以上任意一项设置，即可缩小支持人员的访问范围，无需搭建特定于支持人员的系统。
仅授予任务所需的访问权限。大多支持人员在拥有适度操作空间时运行效果最佳，因此请按照任务需求划定权限范围。对于真正敏感的系统，需要专门禁止支持人员访问。
如何管控支持人员在工作流中执行的操作？
第二项护栏便是工作流：由相关规则决定支持人员何时运行、哪些操作可自主完成，以及哪些调用操作需要等待人工介入。它能够防范任务偏离预期与不可逆操作带来的风险。您可直接在团队现有的流转上配置这些规则，因此监管不再只是流程末尾的单一关卡。
流转条件用于限制支持人员可执行操作的阶段；验证器拦截尚未就绪的工作；审批步骤则将高影响变更交由人工处理。人工审批只是多项规则中的一种，关键是让每一条规则与对应的风险相匹配。
如何在 Jira 中进行配置：打开对应工作类型的工作流，在某一条流转上添加支持人员。例如，进入“待审查”环节，这样当工作项流转到此节点时，支持人员就会启动运行。添加支持人员只是设定它何时运行，并不会开启人工审批。人工审批属于一项独立管控手段：通过工作流审批步骤对流转进行关卡控制。您还可以搭配支持人员自带的“何时暂停并发起问询”指令，或是一条自动化规则一同使用。流转只是若干入口之一。支持人员也可在以下场景启动：
工作一经创建，支持人员便可在工作单生成的瞬间就完成分类
标签或字段发生变更时；或者按照计划表触发，通过自动化规则运行
支持人员在后台执行常规更新任务，例如起草发布说明。
关卡管控与风险等级相匹配。低风险工作允许支持人员自主执行（例如升级依赖关系）；中等风险工作通知相关人员知晓（例如修改共享配置）；高风险或不可逆转的操作则必须经过审批（例如访问生产环境、删除数据）。
确定支持人员负责哪些任务。明确支持人员负责的内容要早于设置检查节点。允许支持人员全权负责低风险工作；高影响工作由支持人员先做准备，再交由人员完成；最高风险的调用始终由人工把控。划定任务边界是首要决策，而检查节点则是落地执行管控的手段。
为支持人员提供专属指令。您可以设定支持人员应当如何行事、如何推进工作，包括哪些决策由它自行做出、何时需要暂停并发起问询。这样支持人员就能够遵循团队的惯例，而非采用通用的默认配置。
审查输出成果：您该如何验证支持人员生成的内容？
第三项护栏就是对工作成果本身进行审查，由人工在结果落地生效之前，排查出低质量输出与幻觉问题。对于编码支持人员而言，审查对象就是它所创建的拉取请求。
在 Jira 中：在人工或者您现有的检查机制完成验证之前，请将支持人员的输出视为不可信内容，审查标准与您对待一名新贡献者提交代码的标准保持一致。支持人员所完成的工作会关联至对应的工作项；代码变更将以拉取请求的方式提交，以执行您日常的审查与合并流程。支持人员产出的所有内容均不得跳过团队开展的审查流程。
查看输出内容背后的工作。您看到的不应只有最终结果。Jira 中的支持人员会话提供统一入口，可查看支持人员执行了哪些操作及其背后原因。这样审查人员就拥有完整上下文来理解输出内容，无需重建。
图注：示例：在 Bitbucket Cloud 中定义人工智能代码审查标准，并针对每一条拉取请求自动强制执行这些标准。
留存可追责记录：何人执行了哪些操作，以及操作发生在何时？
第四项护栏就是记录，这是实现问责的关键。它将支持的工作和意图关联起来：记录支持人员执行了什么操作、执行原因、服务于哪一个工作项，以及审批人是谁。一旦出现问题，依托这条关联链路就能够轻松追溯事务，并回退相关操作。
在 Jira 中：每一个支持人员都以明确的身份运行：要么是分配任务或完成配置的人员身份，使用该人员的权限执行操作；要么使用独立的支持人员帐户，权限由您进行分配。无论采用哪种方式，记录都会将每一项操作绑定到可追责的身份。记录会保存支持人员执行的操作以及对应的责任人，和人工活动一同记录在工作项历史记录中；审批记录与签字确认的审查人员相绑定。管理员还可查看审核日志，以监控异常活动。
将本地支持人员工作纳入记录。支持人员会话跟踪可采集本地 IDE 或终端中本地人工智能编码支持人员产生的活动，并关联至工作项，让 Jira 之外完成的工作也能统一留存于可追溯记录中。注册以加入候补名单。
支持人员护栏的最佳实践有哪些？
将支持人员的访问权限与任务相匹配，随着可信度提升再扩大权限范围（支持人员使用 Jira 现有权限）。
为支持人员提供明确的说明，告知其应当如何执行，以及何时暂停操作并向人请示。
让支持人员先执行低风险、可逆的工作，再处理高影响任务。
关键决策保留人工介入，设置多处检查节点，而非仅做最终审批。
支持人员输出内容采用与人工输出内容相同的评审流程（拉取请求评审与合并）。
支持人员的全部操作均作记录，并关联至工作项（历史记录与审核日志）。
为支持人员提供充分上下文以控制成本，因为开销失控源于支持人员凭空猜测、重做工作。
Atlassian 发现，依托 Teamwork Graph 构建的人工智能，将回答质量提升 44%，同时令牌消耗量降低 48%。
哪些护栏由 Jira 实现，哪些需要依赖其他系统？
护栏分布在您的支持人员技术栈的多个层级。Jira 负责工作与访问层；其余层由您的模型提供商、支持人员框架以及 CI 负责。
Jira 强制执行的护栏 | 在您的技术栈其他位置处理的护栏 |
通过 Jira 权限与项目配置限定支持人员访问范围 | 筛选或审核模型输出（由模型提供商执行） |
在工作流流转时为工作设置人工审批关卡 | 运行支持人员的模型或执行运行时（Jira 编码支持人员运行于 Atlassian 提供的沙盒中；第三方支持人员在其自有框架内运行） |
在工作项历史记录以及管理员审核日志中记录支持人员的操作 | 拦截所有提示词注入攻击（筛选手段有辅助作用，但无法做到全部拦截；即便攻击穿透防护，Jira 可限制其造成的破坏）。 |
为各项任务设置自主执行或审批关卡执行模式 | 强制执行代码层面检查，例如测试与安全扫描（由您的 CI 管道执行） |
Jira 管控支持人员可执行的操作并记录其行为；它补充模型层级与运行时层级的安全防护，而非取而代之。
如何在 Jira 中添加您的第一道支持人员护栏
您无需搭建一套完整的治理方案即可起步。一道护栏便能让您负责任地将实际工作交由支持人员处理，重要决策由人员把控，并可随着信任程度提升逐步扩展。
挑选一项常规、可回滚的任务，例如不稳定测试或依赖版本升级（控制出错带来的损失）。
使用您赋予新团队伙伴同等访问权限运行支持人员，权限不超出任务所需。
将该任务添加至工作流流转节点，要求先经人工审批（拦截偏离目标或存在风险的操作）。
通过现有常规流程审查拉取请求（发现低质量输出或幻觉）。
确认相关操作已记录在工作项中（便于需要回退时追溯）。
这就是构建可负责任地规模化应用人工智能的工作流方式：支持人员输出质量更佳、审查耗时更少，同时获得可安全拓展的自主执行能力。
请查阅我们的《负责任人工智能治理务实指南》，该文档属于《Atlassian 负责任技术原则》的一部分。
关于人工智能支持人员护栏的常见问题解答
如何保障人工智能支持人员的安全？
您可以通过管控其可访问范围、高影响操作设置人工审批、记录支持人员的全部行为，并依据每项任务的风险等级匹配对应的监督，以此保障人工智能支持人员的安全。
Jira 如何治理人工智能支持人员？
Jira 通过您团队已在使用的管控机制治理人工智能支持人员：支持人员在 Jira 的权限与工作流范围内运行，您可在工作流流转节点设置人工审批关卡，并且支持人员的操作会记录于工作项历史记录及审核日志中。
Jira 中的人工智能支持人员是否可以要求人工审批？
可以。您可以将支持人员添加至工作流流转节点，以便在工作推进之前由人员审查和审批其输出内容，同时对低风险、可回滚的任务保留自主执行权限。
人工智能支持人员遇到提示词注入问题时该如何处理？
提示词注入是指试图诱导支持人员执行非预期操作的不受信任输入。Atlassian 会对由 Rovo 支持的支持人员的输入内容进行筛选，拦截注入尝试；但由于不存在万无一失的筛选器，多层护栏将管控剩余风险：受限访问权限、人工审批以及完整的审核轨迹。