作者 / 来源：中智凯灵 / AiDD
【篇首语｜企业 AI，正在从“会用”走向“能交付” 】
第六日，把视线转向 Agent 的控制边界：当它开始调用工具、访问数据和执行动作，谁来决定它能做什么、不能做什么？
国庆七日谈·第六日｜控制边界
▼
当 AI 只负责回答问题，最常见的风险是答错。但当 Agent 可以发起 API 调用、修改业务数据、提交代码、触发流程，风险就从“说错一句话”变成了“做错一件事”。
这时，提示词里的“不要越权”“谨慎操作”“高风险动作请确认”，远远不够。
提示词可以表达意图，却不是强制权限系统。模型可能误解目标，工具可能被错误路由，上下文可能缺失，账号也可能遭到滥用。如果系统只依赖 Agent 自己记住哪些事不能做，本质上是在让执行者同时担任权限管理员和审计员。
2026 年 AiDD 上海站、北京站和成都站的三场分享，从可控 Agent、业务风控和人机协作制度三个方向给出了一条共同线索：Agent 的生产边界，必须从一句“禁止”变成一套可执行、可审计、可撤销的控制系统。
▍从“会调用工具”到“有权调用工具”，中间差一整套控制面
在 AiDD 北京站《从大模型到 AI 执行系统：构建企业级可控 Agent 体系》中，NoDesk AI CTO 王仿把生产级 Agent 的控制拆成五个方面：目标、规划、行为、权限和变更。
图 1：王仿《从大模型到 AI 执行系统：构建企业级可控 Agent 体系》：目标、规划、行为、权限与变更构成五类控制面（PPT 第 10 页）
这个拆分回答了一个经常被混在一起的问题：Agent “能做什么”，至少包含五层不同含义。
目标层决定任务对象、范围和完成标准；规划层限制步骤范围、循环次数和停止条件；行为层定义哪些关键动作必须审核；权限层限定它能访问哪些工具、数据和执行能力；变更层则管理模型、提示词、Skill、知识与配置怎样评估、发布和回滚。
只控制其中一层，边界仍可能失效。即使工具权限收得很紧，如果目标含混，Agent 仍可能在授权范围内做错事；即使目标正确，如果规划没有停止条件，也可能不断调用工具；即使前两者都正确，如果一次配置变更绕过评估，原有边界仍会漂移。
所以，“谁来决定”不能只等于“谁点了一次同意”。它首先要被拆成不同的控制问题。
▍决定边界的，不是一个万能审批人，而是多角色分权
王仿的课件还把企业 Agent 的建设分给三类角色：业务专家制定标准，业务运营长期使用并参与人工审批，技术团队负责 Agent 的开发、权限注册和运维。
图 2：王仿《从大模型到 AI 执行系统：构建企业级可控 Agent 体系》：业务专家、业务运营与技术团队共同定义和维护 Agent 边界（PPT 第 27 页）
这比把所有责任交给“Agent 管理员”更接近真实企业。
业务专家最清楚什么结果正确、哪些例外不能自动处理；业务运营知道现场何时需要介入、哪些异常必须升级；技术团队负责把规则变成权限、工具契约、运行配置、日志和告警。安全、合规和发布责任人还要参与高风险授权与例外审批。
这些角色可以因组织规模而合并，但制定标准、执行动作、复核结果和批准例外不应完全混成一个权力点。否则，无论这个权力点是一个人还是一个 Agent，都很难形成真正的制衡。
第一条边界：把人机分工写成可执行制度
在 AiDD 成都站《在不确定性中重建软件工程确定性：Harness Engineering 与 SDD》中，英湃数字科技 Inspire Group AI4SE 首席顾问邱娟提出，要把人机协作写成制度：角色、自治动作、人工介入、风险升级、交接物、问责和审批都要明确。
图 3：邱娟《在不确定性中重建软件工程确定性：Harness Engineering 与 SDD》：人机协作需要明确角色、边界、交接、问责与审批（演讲 PPT 第 20 页）
这意味着，控制边界不能只是一份“禁止事项清单”，还要说明三件事。
第一，Agent 在什么范围内可以自行行动；第二，出现什么信号必须停止并升级；第三，升级时要把哪些证据交给谁。
例如，同样是修改代码，生成候选补丁、在隔离环境运行测试、合并主分支和触发生产发布，风险等级完全不同。把它们笼统写成“允许使用代码工具”，会让授权范围过大；把它们全部设成人工逐次确认，又会失去自动化价值。
更好的做法是把“工具”拆成具体动作，把“人工审批”放在真正高风险的节点。
第二条边界：Agent 必须运行在受控环境里
邱娟的课件将 Harness 概括为围绕 Agent 构建上下文、工具、权限、反馈和治理环境，并将权限与审计、记忆组织、成本控制放进同一个执行框架。
图 4：邱娟《在不确定性中重建软件工程确定性：Harness Engineering 与 SDD》：围绕 Agent 建立工具接入、权限审计、反馈、记忆与成本控制环境（演讲 PPT 第 28 页）
本文不再展开 Harness 的完整定义，只看其中与控制边界直接相关的一点：Agent 不能直接面对一个毫无限制的生产世界。
受控执行环境至少要回答：它当前代表哪个身份，允许调用哪些工具，参数范围是什么，可以访问哪些数据，结果能写到哪里，失败后怎样停止，哪些状态需要保留，哪些动作必须留下审计证据。
工具契约也不能只写“工具名称”和“功能简介”。一个可治理的工具调用，还需要明确输入输出、参数校验、授权范围、异常分支、停止条件、回写方式和执行证据。
“接上 API”只是技术连通；“获得业务授权”是另一件事。两者不能混为一谈。
第三条边界：权限要贴着业务动作，而不是只盯着模型输出
在 AiDD 上海站《大模型服务的安全防线：全栈式风控与Token可信调用实践》中，腾讯云天御资深安全架构师薛锋把风险控制放进一条完整业务动作链：注册、登录、API 与 Token 消耗、内容输入、营销活动、账号与资源管理，各自对应不同的核验和处置方式。
图 5：薛锋《大模型服务的安全防线：全栈式风控与Token可信调用实践》：不同业务动作需要不同的风险核验和处置机制（演讲 PPT 第 10 页）
这组材料虽然来自大模型服务风控场景，却能给 Agent 权限设计一个重要启发：控制不能只发生在模型输出文本的末端，而要贴着动作发生的位置。
读取一份公开文档、查询客户信息、修改价格、导出数据、发送通知、删除资源，不能共享同一套授权。即使它们都由同一个 Agent 发起，也应该依据数据敏感度、动作副作用、影响范围和可恢复性，设置不同边界。
尤其是修改账号、解绑身份、调整资源、发布生产变更等敏感动作，需要额外核验、持续监控和异常冻结。边界不是“这个 Agent 可以使用某个系统”，而是“它在什么身份、什么场景、什么对象和什么动作上被允许到哪一步”。
第四条边界：一次登录，不等于永远可信
静态角色权限只能说明“理论上允许”，却不能说明“当前这次调用仍然可信”。
薛锋的课件把设备、账号、环境、行为和场景等信息组合起来，用多维信号判断风险。它提醒团队：同一个身份，在不同运行状态下，风险可能完全不同。
图 6：薛锋《大模型服务的安全防线：全栈式风控与Token可信调用实践》：账号、设备、环境、行为与场景共同形成动态风险信号（演讲 PPT 第 16 页）
对于 Agent，这种动态判断可以转化为一组工程问题：调用是否来自预期的运行环境？工具和账号是否匹配当前任务？访问频率是否异常？参数和对象是否偏离任务范围？是否出现连续失败、重复尝试或意外扩张？
这些信号不一定直接判定“恶意”，但可以触发更严格的控制：缩小权限、要求二次确认、降低调用频率、暂停执行、阻断动作或转交人工。
这也说明，身份认证不是控制链的终点，而是动态授权的起点。
第五条边界：权限应当能升、能降，也能被收回
薛锋课件中的 Token 防刷方案，不是给每个已登录账号相同配额，而是结合设备、账号和风险信号，动态调整调用频率与 Token 配额，并对高风险请求进行拦截或降级。
图 7：薛锋《大模型服务的安全防线：全栈式风控与Token可信调用实践》：调用频率与配额可随风险变化，并触发降级或阻断（演讲 PPT 第 14 页）
这类机制不能直接外推为所有 Agent 系统的实现，却提供了一个重要原则：授权不是一次性发放后永久有效。
低风险、可恢复、范围清楚的动作，可以在既定策略内自动执行；风险上升、行为异常或任务越界时，系统应收紧权限，直到暂停或阻断。任务结束、身份变化、配置变更或异常发生后，原有授权也应重新评估。
真正可控的系统，不只会“给权限”，还要能及时“降权限”和“停权限”。
第六条边界：没有审计证据，就没有可追责的授权
王仿的课件把企业担忧进一步落到具体控制项：身份权限、最小授权、Agent ID 隔离、数据脱敏、访问审计、人工确认点、运行监控、异常告警、审计日志、节点回放和全链路 Trace。
图 8：王仿《从大模型到 AI 执行系统：构建企业级可控 Agent 体系》：身份隔离、最小授权、访问审计、运行监控与节点回放共同支撑生产治理（PPT 第 34 页）
审计不是简单地“多记一些日志”。真正有用的证据链需要回答：谁以什么身份发起任务，使用了哪一版规则和配置，获得了什么授权，调用了哪个工具和参数，读取或修改了什么对象，系统为何放行、降级或阻断，过程中是否有人确认，最终结果如何。
只有这些证据可以关联、查询和回放，企业才能复盘一次错误究竟来自需求、权限、工具、模型、配置还是人工审批。
有日志不等于已经合规，但没有证据，几乎不可能完成追责和持续改进。
第七条边界：人工接管要按风险路由，而不是处处盖章
邱娟把人机协作分为 HITL、HOTL 和 HOOL：人在回路中直接批准，人在回路上监督，或人在回路外让系统在策略内自治。关键不是选择一种模式贯彻到底，而是按动作风险路由。
图 9：邱娟《在不确定性中重建软件工程确定性：Harness Engineering 与 SDD》：不同阶段按风险在 HITL、HOTL 与 HOOL 之间路由（演讲 PPT 第 21 页）
探索、检索、草稿生成等低风险动作，可以让 Agent 在边界内自治；执行阶段可以在受控环境中小步进行，并在风险上升时升级人工；计划签署、独立评审、合并发布和生产变更，则应保留明确的人类责任节点。
这避免了两个极端：一边是所有动作都要人工逐次确认，流程被审批拖死；另一边是一次授权后全部自动执行，异常直到造成结果才被发现。
人工接管不是自动化的例外，而是分级控制系统的一部分。
企业给 Agent 开放工具前，先检查七件事
第一，Agent 是否拥有独立身份，而不是多人共用一个无法区分责任的账号？
第二，权限是否按任务、数据、工具和动作拆分，并遵循最小授权与角色隔离？
第三，工具契约是否明确输入输出、参数范围、异常分支、停止条件、回写方式和审计证据？
第四，执行是否发生在受控环境，是否有白名单、状态保存、异常停止与回退路径？
第五，系统是否会结合身份、环境、行为和场景动态调整权限、频率与处置？
第六，关键动作是否能关联授权、参数、结果、人工确认、日志与回放记录？
第七，低风险动作、高风险动作与越界动作，是否分别对应自动执行、人工接管和阻断收回？
如果这七件事还说不清，Agent 获得的不是生产能力，而是一组尚未被治理的系统权限。
结语：控制边界不是限制智能，而是让智能进入真实业务
北京站的可控 Agent 体系说明，目标、规划、行为、权限和变更需要分开治理，多角色共同决定边界；成都站的人机协作框架说明，自治、介入、升级、审批与问责必须写成制度，并在受控环境中执行；上海站的业务风控实践则说明，授权判断必须贴着真实动作，结合动态风险信号决定放行、核验、限流、降级、阻断或冻结。
所以，“谁来决定 Agent 能做什么、不能做什么”的答案，不是模型自己，也不是某一个审批人。
它是一套由业务规则定义、组织角色分权、身份权限强制、工具契约约束、执行环境隔离、动态风险策略调整、审计证据留痕，并由人承担最终责任的控制系统。
边界写得越清楚，Agent 才越有可能获得更大的自主空间。可控不是把它关住，而是让企业敢于把更真实的任务交给它。
国庆七日谈·第七日，我们收束七层能力，继续讨论：企业有了 100 个 Agent，为什么还不等于有一支 AI 团队？
主要参考演讲
下一站
北京营销中心
北京通州北京ONE国际广场10层
上海研究中心
上海市浦东软件园
厦门研究中心
厦门观音山国际商务运营中心
海外市场中心
香港中环香港站国际金融中心
加入智库
成为客户
