AI编程代理（能自己写代码、自己运行代码的AI助手）几分钟就能把一句大白话变成一个能用的脚本。对分析师、运营主管或交易员来说，原来要花一下午的报表，现在一杯咖啡的工夫就做完了。同一个工具也可能带来另一种结果：一段没人审过的程序，带着这名员工的全部权限，跑在存着客户文件的那台电脑上。两种结果出自同一个工具，公司把它发下去之前，得先想清楚自己能接受哪一种。
非技术员工使用AI编程代理，是指财务、销售、法务、运营等本职不是写软件的人，借助代理替自己编写并运行代码。公司要做的决定，很少是简单的「给」或「不给」。它拆开来是几个更具体的问题：谁可以运行代理，代理运行时能碰到什么，代理写出的东西开始被别人使用之后怎么办。把这三件事明确定下来的公司，通常能保住大部分好处；任由它们含糊下去的公司，往往要等出了事再把权限收回来。
本文依次讲：编程代理和聊天助手有什么区别，使用者不是工程师时会多出哪些问题，金融监管和安全标准已经说了什么，怎样分级授权，以及怎样把一个好用的个人脚本交接成有人负责的正式工具。文中以高盛 2026 年 10 月把 Claude Code 限定给工程师使用一事为带日期的实例，因为这是目前记录最完整的案例，其他公司做出不同选择同样合理。
01编程代理和聊天助手的区别
聊天助手输出的是文字。人读完，判断对不对，再把需要的部分复制到别处。即便输出的是代码，也得有人把它贴进文件、亲手运行。也就是说，代码第一次碰到真实数据时，旁边一定站着一个人。
编程代理把这一步省掉了。它会读取文件夹里的文件，写新文件，执行命令行指令，安装软件包，访问网页和其他工具，再根据结果决定下一步。Claude Code、Codex、Cursor 的代理模式、GitHub Copilot 的代理功能都是这样工作的，只是默认设置不同。代理通常继承启动它的那个人的系统权限。这个人能打开客户文件夹，代理就能打开；这个人的电脑连得上交易网络，代理写出的任何程序也连得上。
厂商清楚这一点，产品里都带有权限系统。以 Claude Code 的官方文档为例，它列出了几种权限模式：默认模式下，代理第一次使用每个工具前都会询问；计划模式下，代理可以阅读和探索，但不改源文件；「auto」模式不再逐条询问，由一个后台分类器检查命令行指令、网络请求等操作是否符合用户的要求；「bypassPermissions」模式几乎跳过所有询问，文档写明只应在「容器或虚拟机这类 Claude Code 无法造成破坏的隔离环境」中使用。
对本文来说，同一份文档里有一句话比所有模式都重要：「权限规则由 Claude Code 执行，而不是由模型执行。」写在提示词或项目文件里的要求，只影响代理想做什么，改变不了工具允许做什么。公司想让某条限制真正生效，就得把它写进工具的设置里，或者放到工具下面一层，也就是操作系统和网络里，靠一句「请代理守规矩」是不够的。
这份文档也坦白交代了设置管不到的地方。禁止读取文件的规则，只对代理自带的文件工具和点名文件的常见命令生效，对「自己打开文件的 Python 或 Node 脚本」不起作用。想要一条对所有进程都有效的限制，文档建议使用它的沙箱，沙箱在操作系统层面起作用。这个细节对非技术员工特别关键，因为他们让代理写的脚本，恰恰就是这种自己打开文件的程序。
02使用者不是工程师时会多出哪些问题
在管理规范的公司里，工程师用编程代理时，身边有一整套为代码准备的习惯和系统：改动进版本控制，另一名工程师审查，自动测试会跑，部署到重要系统还要走一条有审批的流水线。这些都不完美，但代理写的代码到达生产数据之前，通常要过好几道检查。
非技术员工用同一个代理时，身边一般什么都没有。监控客户报表或者重建定价表的脚本，就放在下载文件夹或个人网盘里，没有第二个人看过。周二跑通了，周三就接着用；过一个月，可能已经有两个同事离不开它。这名员工通常没有地方安放这段代码，代理也没有提醒应该放到哪里去。
还有一个问题：有没有人真正明白这段代码在特殊情况下会怎么做。交易员或会计能看出平常日子里的结果对不对，但不太可能知道脚本遇到缺失的价格、节假日日历、从没见过的币种时会怎样处理。在交易台上，在月末结账时，亏损恰恰出在这些边角情况里。
第三个变化是电脑本身。一名金融从业者的工作电脑上，通常同时有客户数据、内部邮件、互联网连接和通往内部系统的通道。安全研究者 Simon Willison 把AI代理身上与此相关的一种组合称为「致命三要素」：能接触私密数据，会读到不可信的内容，能向外部发送信息。三样齐全时，网页或文档里一句被人藏进去的指令，理论上就可能让代理把私密数据发出去。开发者的电脑当然也常常三样齐全，差别在于工程团队更常把代理放进容器或独立环境里运行，而非技术员工大多不知道还有这个选项。
成本也会变化，只是没那么显眼。编程代理一般按用量计费，刚上手的人很容易在本该用表格解决的事情上花掉一大笔钱。我们的《AI代理要花多少钱》一文算过这笔账。成本很少单独促成限制，但在效率说不清的时候，它会让天平更快倾斜。
实例：高盛把 Claude Code 限定给工程师使用（2026 年 10 月至 11 月）
彭博社 2026 年 11 月 2 日报道，高盛已把 Anthropic 的 Claude Code 和微软 GitHub 的编程工具限定为只供工程师使用，依据是 10 月更新、彭博社看到的一份内部指引。在此之前的几个月里，高盛允许投行人员在工作中使用这些工具。报道称，这一调整是在评估了效率和风险方面的顾虑之后做出的。
据彭博社援引的一名知情人士，部分交易员对此不满。他们一直用这些工具监控客户交易流量、对市场变化和持仓建模，以及制作文字和图表材料。另一名知情人士说，这项规定不适用于「strats」，也就是横跨交易、量化研究和软件工程的那批员工。
时间点耐人寻味，因为几个月前高盛还在推崇相反的做法。据彭博社报道，7 月份，首席信息官 Marco Argenti 谈到了交易员、投行人员等非技术员工的「vibe coding」（凭感觉让AI写代码）：他们用AI工具做出解决方案，再交给公司 12,000 名工程师中的一位去完善。2026 年早些时候，高盛还限制了香港员工使用 Claude，彭博社称那是一项按地点做出的限制。高盛自建的内部AI助手整合了 OpenAI、Anthropic 和 Alphabet 的模型，报道没有提到它受影响。
高盛发言人 Nick Carcaterra 把这次调整说成试用期的结束：「我们向员工提供某些AI工具，是为了找出它们在公司不同部门的最佳用途。经过一段试验期，我们会评估包括效率和风险管理在内的多方面因素，然后把工具交给最适合长期使用它们的人。」
11 月 8 日，一篇转述文章登上 Hacker News 首页，拿到近 600 分、350 多条评论，这件事又传开一轮。这些评论作为高盛内部情况的证据用处不大，作为从业者怎么看这个问题的样本却很有参考价值。一位自称接手过业务部门这类工具的评论者说，首席信息官口中的「完善」二字「扛了很多分量」。另一位列出了银行围绕任何应用都得管的事：访问授权、数据隐私、数据许可、可审计的访问记录和审批链。还有一位持相反看法，认为工程团队应该「为投行人员设计一个让他们伤不到自己的编程环境」。这些都是个人看法。它们说明分歧主要在于怎样安全地放开权限，大家并不怀疑非技术员工能从中得到价值。
这个实例有两点局限。彭博社的消息源没有说哪一项风险最关键，高盛也没有公开评估结果。比这更具体的说法，包括评论者对「发生过操作事故」的猜测，都属推测，本文不采用。另外，高盛是 Anthropic 计划中上市的主承销商之一。可见一家公司限制某一类员工使用某个产品，并不代表它对这家供应商的整体看法。
03相关监管文件和安全标准怎么说
目前还没有哪家监管机构发布过规定，明确哪些员工可以使用AI编程代理。不过有几份现行文件依然适用，放在一起读，能搭起一个不错的起点。下表汇总了本文核对过的四份。
| 来源 | 内容要点 | 对代理写出的工具意味着什么 |
|---|---|---|
| FINRA《2026 年度监管监督报告》生成式AI一节 | 列出代理风险，包括未经人工验证就自主行动、超出用户「实际或预期的范围和权限」行事、多步推理难以追溯 | 监督流程可能需要「针对所部署代理的类型和范围」专门设计，包括在哪些环节保留人工把关 |
| OWASP《大语言模型应用十大风险（2025）》LLM06 过度代理 | 根源在于功能过多、权限过大、自主性过高 | 只给代理完成任务所需的功能、权限和自主程度，高影响操作要人工批准 |
| 美联储、OCC、FDIC《模型风险管理修订指引》（SR 26-2，2026 年 4 月 17 日） | 生成式和代理式AI模型不在适用范围内，但其原则适用于传统统计和量化模型 | 代理本身不在范围内，代理写出的持仓或定价模型却很可能在范围内 |
| 美国《证券交易法》第 15(g) 条 | 券商必须制定书面政策，防止滥用重大非公开信息 | 在不同部门之间搬运数据的工具，不论谁写的，都可能越过信息隔离墙 |
FINRA 那一节最直接。它把AI代理定义为「能够代表用户自主执行并完成任务」的系统，列出的风险里有一项是数据敏感性：代理「可能在无意中存储、探查、披露或滥用敏感或专有信息」。它没有规定具体管控措施，但建议公司考虑设置「限制或约束代理行为、操作或决策」的护栏。
模型风险指引需要读得更细一些。2026 年 4 月，美国银行监管机构用 SR 26-2 取代了沿用十五年的 SR 11-7，把生成式和代理式AI模型排除在适用范围之外，同时说明，对指引未覆盖的工具，银行仍应按自身的风险治理做法确定管控。指引对「模型」的定义是「运用统计、经济或金融理论，把输入数据加工成量化估计的复杂量化方法、系统或手段」，并排除了表格里的简单算术和确定性的规则类软件。按这个定义，一个把客户流量抄进汇总表的脚本，大概不算模型；一个估算市场冲击下持仓如何变动的脚本，很可能就算。写出第二个脚本的代理不在指引范围内，脚本本身却可能和其他模型一样，要进清单、要验证、要接受「有效质询」。大多数用代理的非技术员工不会知道这一点，所以公司需要一条路径，把这类工具送到懂行的人面前。
OWASP 的框架在金融以外同样好用，因为它的三个根源正好对应公司能调的三类设置。功能，是代理有哪些工具；权限，是这些工具能碰到什么；自主性，是代理不经询问能做多少事。三者可以分别收紧，运营分析师合适的程度和平台工程师合适的程度并不一样。
第 15(g) 条只适用于美国券商，某个工具是否违反公司的信息隔离政策，属于法律和合规问题，应由专业顾问判断。把它列进来，是因为它说明了一个普遍的道理：关于谁能看到什么信息的规则，原本是为人和系统写的，员工借助代理做出来的软件同样受这些规则约束。
04授权问题可以拆成哪三个决定
多数公司一开始把问题当成一整个来问：这个团队给不给编程代理？这样问，答案往往是全有或全无，高盛的情况大致如此。更可行的做法是拆成三个决定，各有各的负责人。
第一个决定是谁可以运行会执行代码的代理。这关乎岗位和培训。从没见过命令行的人也能从代理身上受益，只是可能需要一个限制更多的版本。
第二个决定是代理运行时能碰到什么。这关乎运行环境。同一个人，在沙箱里对着上个月的数据副本用代理，可能很安全；在自己的主力电脑上，连着实时客户文件夹和开放的互联网用代理，就不安全了。前面讲的大部分风险集中在这里，而且不用收回工具也能调整。
第三个决定是产出去往哪里。一个人为了回答一个问题跑一次的脚本，和十个人每天早上都要用的脚本，是两样东西。前者可以一直留作个人用途；后者需要负责人、需要审查，还要登记进公司的清单。我们之前写的《AI代理泛滥》讲的是代理本身的清单问题。往下一层，代理做出来的工具也有同样的问题。
拆开之后，责任也清楚了。直线经理和人力资源了解岗位，IT 和安全团队掌管环境，工程、风控或模型验证团队可以负责工具进入共享使用的那条路。要是一个团队得同时回答三个问题，它多半会往保守里答，因为所有坏结果都算在它头上。
05非技术员工能从编程代理中得到什么
很容易把限制理解成「非技术员工就不该用这些工具」。高盛报道里提到的用途说明的恰恰相反：监控客户流量、给市场变动建模、制作文字和图表材料，都是实打实的工作，员工选择用代理，是因为它确实帮得上忙。
金融以外也是这样。运营主管要核对两份永远对不齐的导出数据；法务助理要从四十份合同里把条款编号拉进一张表；市场分析师要把一张乱糟糟的投放表格变成每周图表。Hacker News 讨论里有位评论者说，家里一位当医生的亲人在用 Claude Code 做一些「和代码沾边、但并不产出给别人用的代码」的事，比如一个打包清单小工具，还有管理家里的通讯录。这些场景里，当事人比任何可能被派来做工具的工程师都更懂问题本身，代理省掉了排队等工程资源的时间。
还有一个容易被忽略的好处。离问题最近的人亲手做出的原型，本身就是一份精确的需求说明。即便工程团队最后推倒重写，那个能跑的版本也展示了用户真正要什么，而这常常和他们填进工单里的描述不一样。Argenti 7 月讲的业务人员把工具交给工程师完善，说的其实就是这件事。薄弱环节在交接，后面「个人脚本如何转为共享工具」一节专门讲。
好处大小在很大程度上取决于任务类型。在本来就有权查看的数据上做一次性分析，风险很小；只读数据、只给自己生成文件的个人工具，风险略高一点；工具一旦开始操作其他系统、为其他人服务，风险就会陡然上升。
06风险集中在哪些情形
非技术员工使用编程代理的风险分布很不均匀。绝大多数用法无害，少数用法承担了大部分风险敞口，而且它们往往有几个共同特征，通常能及早认出来。
第一个特征是多人共用。一旦有别人依赖脚本的输出，它就不再只是个人的便利。这时出了错，写脚本的人发现不了，用脚本的人又不知道它怎么运作。共用的工具也活得最久，常常比做它的那名员工在公司待得还久。
第二个特征是接触受监管或敏感的数据：客户记录、交易数据、个人信息，以及处在信息隔离墙后面的交易信息。一个代理既能读这些数据、又能连互联网，就是前面说的「三要素」情形。我们的《AI代理数据泄露》详细讲了从网页请求到提交记录、日志的各条出站渠道。
第三个特征是执行操作。读取并汇总的脚本，和会发邮件、记一笔账、下一张单、修改共享系统里的记录、删除文件的脚本，完全是两回事。FINRA 担心的代理「超出用户实际或预期的范围和权限」行事，在这里最突出。一个人有下单权限，这个人运行的脚本就继承了这份权限，除非有别的东西拦着。
第四个特征是凭证。调用内部系统的代理需要密钥或令牌，非技术员工处理这些东西的方式常让安全团队捏一把汗，比如直接贴进提示词，或者用明文文件存在脚本旁边。《AI API 密钥自持清单》讲了哪些密钥该由谁保管。
第五个特征藏在看似无害的工具里，值得单独点出来：量化判断。一个做估算、预测或定价的脚本，内嵌着各种假设。假设错了，输出照样可能看起来合情合理。银行业的模型风险指引就是为此而设的。其他行业也许没有正式流程，问题却一样存在。
07如何按岗位分级授权
分级做法让公司能对大多数用法说「可以」，同时把高风险的组合留给审查。下面是一种可行的分法，具体边界因公司而异。描述每一级时，除了写岗位，还要写清楚对应的设置和运行环境。
| 级别 | 典型使用者 | 代理能做什么 | 在哪里运行 |
|---|---|---|---|
| 0 级：辅助 | 所有人 | 回答问题、起草内容、建议代码；不在用户电脑上执行任何东西 | 获批的聊天助手或内部AI平台 |
| 1 级：沙箱 | 受过培训的业务人员 | 对数据副本或抽取件编写并运行代码；不联网，或只允许访问白名单 | 有操作系统级隔离的容器、虚拟机或托管工作区 |
| 2 级：工作区 | 有指定工程担保人的熟练用户 | 在实时只读数据上运行；每次写入和联网都要批准 | 由管理员下发、用户无法覆盖的设置 |
| 3 级：工程 | 工程师和量化开发人员 | 在常规审查和部署流程内完整使用工具 | 带版本控制、代码审查和测试的开发环境 |
对很多人来说，0 级已经覆盖了相当大一部分价值。一个好的助手能写公式、解释别人写的脚本、起草一段查询再交给工程师运行。高盛保留下来的内部AI助手，大致就属于这一级。
想用代理的非技术员工，大多应该从 1 级起步。这一级的要点是由运行环境来设定边界，代理自身的设置只是辅助。Claude Code 的文档本身就建议，对必须管住所有进程的限制使用操作系统级沙箱。这一点很要紧，因为代理替业务人员写的脚本都是普通程序，环境里能看到的文件它都能打开。如果沙箱里只有一份数据副本，脚本最坏也只能弄坏这份副本。
2 级留给工具已证明有用、需要实时数据的人。到了这一级，设置本身开始起作用，而且应当统一下发。Claude Code 支持用户无法覆盖的托管设置：托管设置里的禁止规则，用户级的允许规则解不开；管理员还可以直接禁用 auto 和 bypassPermissions 两种模式。其他代理也有类似的管控，把这类能力纳入《主权AI采购标准》的检查项是合理的。指定一位工程担保人，用户遇到问题有人可问，公司也有人知道到底在跑些什么。
3 级就是现有的工程环境。把它列出来，是为了说清楚工程师用代理写的代码同样要过审查。把「只给工程师用」当成问题已经解决，是一种误判。工程师也会把没完全读懂的代理代码发出去，也会在存有敏感数据的电脑上给代理开很大的权限。
在级别之间调整，应当是一件有意为之、留有简短记录的事：谁申请的，为了哪个工具，涉及哪些数据，谁批准的。我们在《私有AI的能力悖论》里说过，「谁批准了什么」是模型再强也替代不了的少数几件事之一。级别调整，正好可以作为开始记录的地方。
关于厂商的方向，这里补充一点。2026 年 11 月 7 日，在一场关于有人把 Claude Code 设置文件提交到公开仓库、导致密码外泄的公开讨论中，Claude Code 团队的一名成员写道，「权限规则已经过时了」，所有人「都应该改用 auto 模式」。这名成员在同一讨论串里给出的理由是：要人批准大量命令，人会疲劳，难免批准了不该批准的命令，自动检查在实践中表现更好。这个理由说得通，而且说的是开发者的场景。放到上面的分级里，要分清的是分类器的判断和统一下发的禁止规则是两种性质不同的管控。公司可以两者都用；对 1 级和 2 级，通常还是希望把禁止规则设在用户改不了的地方。这名成员在同一讨论里还提到了一个开源沙箱，并说任何沙箱都「得打些洞」才实用。这也提醒我们，运行环境同样有它的边界。
08个人脚本如何转为共享工具
从业务人员到工程团队的交接，看起来正是高盛那套做法吃力的地方，也是大多数公司完全没有流程的地方。一条简单的转交路径，能把交接这一步摆到明面上。
第一步是一份轻量的清单。1 级及以上的用户，凡是一个工具用了好几次，就登记一下：一句话说明它做什么、读哪些数据、有没有别人在用。登记要控制在两分钟以内，否则没人会做。清单不是关卡，它的用处是让公司看得见哪些工具正在变得重要。
第二步是触发条件。只要出现前面讲的任一风险特征，工具就转入审查：有了第二个固定用户，接触到敏感数据，会对其他系统执行操作，存有凭证，或者产出供人决策的量化估计。触发了不代表工具有问题，只代表它现在需要一个看得懂它的负责人。
审查的结论应当是三种之一。第一种是纳入：指定一名工程师或一个团队接手，放进版本控制，补上测试，在正规环境里运行。第二种是保留个人使用，同时收紧权限，防止它悄悄变成共用工具。第三种是停用，并记下它原本满足的需求，好用别的办法接上。State of AI 在报道高盛一事时提到，收回一个工具时，值得记下大家原来用它做什么。不管最后怎么决定，这都是个好习惯。
对银行和其他设有模型风险流程的机构，审查这一步应当加一个简单的问题：这个工具是否产出有人依赖的量化估计？是的话，它就该进模型清单，不管它是人写的还是代理写的。
转交路径也让工程团队的接收量变得可控。前面提到那位接手过业务部门工具的评论者说，这些工具更可能「被扔进待办清单的角落」，而不是得到完善。有了清单和明确的触发条件，工程团队看到的是一份附带背景、确实需要处理的短名单，不再是一串没头没尾的请求。
09示例：一家虚构公司如何设置分级
以下示例为虚构，公司、数字和结果均为说明用的假设，目的是展示各个环节如何配合。
一家虚构的投资公司有 80 名员工：20 名工程师，15 名分析师，30 名运营和客户服务人员，15 名其他岗位人员。过去六个月，公司允许任何人自行安装编程代理。制定政策之前，公司先请员工列出自己还在用的代理自建工具，一共报上来 47 个。
这 47 个工具里，31 个只有做它的人自己在用，用于一次性分析或偶尔图个方便。12 个已经变成共用，大多是运营部门的对账和报表脚本。这 12 个当中，有 4 个读取客户账户数据，生成的报告会发给客户。分析师的工具里，有 2 个用来估算投资组合对利率变化的敏感度。
公司把所有非技术员工默认放在 1 级，使用一个托管工作区，里面有他们所需数据的每晚副本，除白名单外不能访问外网。8 名熟练用户（大多在运营部门）升到 2 级，各配一名工程担保人。12 个共用工具全部过审：6 个由工程团队接手，3 个收紧权限后保留个人使用，3 个停用，因为供应商的现成报表已经能满足需要。2 个敏感度工具进入公司的模型清单，接受独立复核。
代价也看得见。员工要花一个下午熟悉沙箱。两名分析师觉得 1 级用于日常工作太慢，申请了 2 级。一个被停用的工具，后来发现客服团队也在用，而之前没人问过他们，只好临时恢复。这些都很常见。最终，公司意外少了，有用的工作量大体没变，这类政策能做到的也就是这样了。
10按岗位授权管不到的风险
分级授权加上转交路径，应对的是一种风险：看不全代码的人写出、没人审过的代码，带着过大的权限运行。其他风险它管不到，最好一一点名。
它管不到发给云端模型的数据。代理调用云端模型时，上下文里的所有内容都会按该服务商的条款发过去，用户在哪一级都一样。这属于供应商和架构问题，有些公司正因如此把敏感工作交给自己托管的模型。
它挡不住提示词注入。沙箱限制了被注入的指令能碰到什么，审批步骤限制了它能做什么，但在这些边界之内，一份文档或一个网页仍然可能误导代理。
它不能保证工程师的代码安全。3 级依靠审查和测试，而这只有在审查者真的读了代理写的代码时才管用。代理写代码的速度越来越超过人能从容检查的速度，这个问题正在变大。
它也防不了影子使用。如果获批的级别太慢、限制太多，员工就会转用个人账户和个人设备。一项把有用工作逼到暗处的政策，只会让风险更难被看见，风险本身并没有变小。我们在《代理集群与企业安全》里也谈过相关的一点：安全和效率用的是同一套权限，把一切锁死，往往两头落空。
11KarmaBox 能解决什么、不能解决什么（产品介绍）
KarmaBox 是一个工作台，分身（各自负责一类明确工作的AI代理）可以在放在你自己办公室的设备上运行，详见 KarmaBox 产品页。据产品页介绍，每个官方分身都有自己的边界，「在服务端强制执行，而不是靠提示词」。设备配有 128 GB 统一内存，功耗约 170 瓦。
KarmaBox 是本文作者团队的产品，所以这一节用同样的问题来检查它。按这些问题衡量，相关的是那些把限制从模型挪到系统里的功能。边界固定的分身，更接近 1 级和 2 级，离个人笔记本上的通用编程代理更远，因为边界由配置工作台的人设定，输入请求的人改不了。在公司自己掌控的设备上运行，意味着业务人员处理数据时，数据可以留在这台机器上，这正是 1 级沙箱想要提供的特性。金融团队可以参考金融行业方案页，那里介绍了一家机构如何决定哪些任务留在本地、审批设在哪里。规模较小的公司可以从企业方案页开始，总体概念见《主权AI工作台》。
对 KarmaBox 要问的问题，和对任何其他产品一样。可以用 KarmaBox 文档核对：哪些分身能运行代码，能碰到哪些数据，哪些操作需要批准，这些设置终端用户能不能改。KarmaBox 不能替公司决定岗位授权，也不是代码审查流水线：在它里面做出的工具，一旦变成共用，同样需要负责人和上面那条转交路径。KarmaBox 也提供云端选项，调用云端模型的分身会把上下文发给相应的服务商。
12常见问题
非技术员工应该在工作中使用AI编程代理吗？
很多时候可以，但要有边界。在本来就有权查看的数据上做一次性分析、做个人工具，风险很小，还能省下大量时间。工具一旦变成共用、接触敏感数据、操作其他系统，或者产出有人依赖的估算，风险就上来了。分级授权能让公司放行前一类用法，同时审查后一类。
高盛为什么把 Claude Code 限定给工程师使用？
据彭博社 2026 年 11 月 2 日报道，高盛在评估效率和风险顾虑之后，通过 10 月更新的内部指引，把 Claude Code 和 GitHub 的编程工具限定为只供工程师使用。量化岗位「strats」不受影响，高盛的内部AI助手也照常可用。高盛没有公开评估结果，更具体的原因外界并不知道。
AI编程代理和聊天助手有什么区别？
聊天助手返回文字，由人阅读和复制。编程代理自己读写文件、执行命令、根据结果采取行动，通常拥有和用户相同的权限。所以对编程代理来说，运行环境和设置比给它的指令更重要。
公司怎样限制编程代理能做的事？
使用由工具强制执行、统一下发且用户无法覆盖的设置，再加上工具之外的限制，比如沙箱、独立虚拟机或网络白名单。以 Claude Code 文档为例，它写明权限规则由工具执行、不由模型执行，而且禁止读取文件的规则管不到自己打开文件的脚本。
模型风险管理规定适用于AI代理写的代码吗？
对美国银行而言，模型风险修订指引 SR 26-2 把生成式和代理式AI模型排除在范围之外，但其原则仍适用于传统量化模型。如果代理写出的脚本产出有人依赖的量化估计，这个脚本就可能属于指引所说的模型。某个具体工具是否在范围内，应由机构的模型风险和合规部门判断。
