一、先算清能力账本：预算体系为何不能从软件报价起步
智能体项目的预算争议，往往不是出在单价高低，而是出在边界模糊。业务部门看到的是对话入口、自动化流程和效率提升，技术团队看到的是模型、算力、数据、接口与运维，财务看到的却可能只是一份软件采购清单。三种视角如果没有被翻译成同一套预算语言，智能体部署解决方案就很容易在立项时显得轻巧，在交付时不断追加，在上线后又缺少持续运营的额度。真正稳妥的做法，是把预算体系前置为能力账本：先确认智能体要承担什么任务、需要哪些数据和工具、由谁维护、按什么口径验收，再讨论采购与自建的比例。预算不是把价格压到最低，而是让投入与可验证的业务价值保持可解释的对应关系。
因此，讨论落地预算时，不能只问“做一个智能体要多少钱”，而要问“这套智能体在什么流程里持续创造价值、消耗哪些资源、由谁对结果负责”。把智能体部署解决方案放回工程与运营语境，隐性成本才会显形，预算审查也才有抓手。
预算体系的第一课，是把“买一个智能体”改写成“建设一项可持续运行的能力”。这会牵出模型服务、算力资源、数据治理、系统集成、流程改造、安全合规、运营监控和迭代优化等科目。若只按功能清单询价，供应商容易把边界压到演示可用，企业则在上线后发现大量工作仍需内部消化。智能体部署解决方案的预算审查，应先看能力边界是否完整，再看价格是否合理；否则低价中标只是把成本推迟到交付之后。
1. 成本边界要按“建设、使用、运营”拆开
成本边界不是把报价单拆得更细，而是把智能体从建设到退出的全周期资源消耗分层。建设期关注场景梳理、知识整理、接口改造、智能体编排和安全评估；使用期关注模型调用、算力弹性、工具调用和并发保障；运营期关注提示词与知识更新、效果监测、异常处置和版本迭代。把这三类成本混在一个总包里，评审时看似省事，执行时却最容易出现追加。智能体部署解决方案若不能在预算表中体现全周期科目，后续每一次优化都可能变成临时立项。
(1) 建设期预算要覆盖“不可见工程”
建设期最容易被低估的，是数据清洗、知识资产结构化、系统接口适配、权限打通和测试验证。这些工作不直接产生演示效果，却决定智能体能否在真实流程中稳定运行。预算评审时应要求把不可见工程单列，明确责任方、交付物和验收方式。智能体部署解决方案的价值不在于把界面做得更像人，而在于把任务闭环、异常回退和责任边界设计清楚。若这部分被塞进“实施服务”一笔带过，后期争议几乎不可避免。
(2) 使用期预算要设置弹性上限
使用期成本与调用规模、并发峰值、工具调用频次和模型选择相关，不能只用静态包年思维覆盖。预算中应设置弹性区间、告警阈值和超限审批机制，让业务增长时有资源保障，也让异常调用能被及时约束。对高频但规则明确的任务，可通过编排与小模型分流；对复杂推理任务，再保留高性能模型通道。这样既避免资源浪费，也防止因预算僵化影响体验。
(3) 运营期预算要预置持续投入
智能体上线后仍需知识更新、效果评估、对话质检、权限复核和版本回滚。运营预算若缺位，系统会在最初可用之后逐步失准，最终被迫以紧急项目方式返工。更合理的做法是把运营工作产品化：设定例行巡检、问题分级、变更记录和效果复盘机制，并按服务级别配置资源。预算表里没有运营科目，组织里就很难有稳定责任，智能体也就难以从演示工具变成生产系统。
2. 价值口径要能约束功能扩张
智能体项目最常见的预算失控，不是单价上涨，而是功能边界不断扩张。今天是问答助手，明天要接工单，后天又要做跨系统执行；每增加一个能力，背后都牵动数据权限、接口改造、测试范围和运营责任。智能体部署解决方案必须用价值口径约束功能扩张：每个能力都要对应明确任务、使用对象、验收指标和退出条件。没有价值锚点的功能堆叠，会让预算从投资变成无底洞。
(1) 以任务闭环而非功能数量计价
功能数量容易比较，任务闭环却更难伪装。评审时应看智能体能否在限定权限内完成从理解需求、调用工具、生成结果到异常回退的完整链路，而不是只看它能回答多少类问题。按任务闭环计价，会倒逼需求方想清楚输入、输出和责任边界，也会让供应商无法用泛化能力掩盖集成难度。预算颗粒度越贴近任务，后续验收越不容易扯皮。
(2) 把验收指标写进预算假设
预算不是孤立数字，它依赖一组假设：知识覆盖范围、接口开放程度、人工复核比例、异常处理时效和业务量波动。把这些假设写成可验证指标，预算才有比较基础。智能体部署解决方案若只承诺“提升效率”而不定义验收口径，追加投入就缺少刹车。更稳妥的方式，是把效果评估、抽样复核和退出机制一并写入预算说明，让每一笔投入都能回溯到假设是否成立。
(3) 为“不做什么”保留预算纪律
预算纪律不仅体现在花多少钱，也体现在拒绝哪些需求。与核心任务无关的展示型功能、缺少数据支撑的复杂推理、责任边界不清的自动执行，都应进入观察区而非直接立项。把“不做什么”写进评审纪要，可以减少后续反复拉锯。智能体能力越强，越需要克制：每增加一个入口，就增加一份权限、监控和解释成本。预算体系要保护这种克制。
二、拆解功能边界：哪些能力该买、哪些能力该建
智能体不是单一软件模块，而是模型、知识、工具、流程和治理的组合。预算讨论若停留在“买模型”或“买平台”，就会忽略真正决定落地深度的能力边界。一个可用的智能体部署解决方案，需要把感知、决策、执行和反馈连成闭环，也要让企业清楚哪些能力应采购成熟服务，哪些能力必须沉淀为内部资产。买与建不是立场之争，而是成本、速度与控制力的平衡。
1. 感知、决策、执行能力要分开评估
感知能力决定智能体能否理解文本、语音、图像或结构化数据；决策能力决定它能否在规则与模型之间做出合适选择；执行能力决定它能否通过工具调用真正改变业务状态。三者成本结构不同，风险也不同。感知层可借助成熟模型快速起步，决策层需要场景规则与评测集，执行层则高度依赖接口治理和权限控制。智能体部署解决方案若把三者打包成一个黑箱，预算评审就很难判断钱花在了哪里。
(1) 感知层避免重复造基础能力
通用语言理解、文档解析、语音转写等基础能力，通常不值得企业从零建设。预算重点应放在领域语料整理、术语适配和输出校验上。智能体部署解决方案在感知层的合理策略，是采用可替换的模型服务，并保留评测与切换空间，避免被单一能力锁定。企业真正需要沉淀的是领域知识和评价标准，而不是重复训练一个通用模型。
(2) 决策层需要规则与模型协同
很多任务并不需要完全依赖模型自由生成。审批、风控、路由、权限判断等环节，规则引擎往往更稳定、更可解释。预算中应体现规则梳理、评测集建设和人机协同设计的投入，而不是把所有决策都推给模型。模型擅长处理非结构化信息和模糊语义，规则擅长约束边界与责任。两者协同，才能既控制成本又保证可审计。
(3) 执行层要把接口治理算进预算
执行层是智能体从“会说”走向“能做”的关键，也是最容易产生隐性成本的部分。接口标准化、鉴权、幂等、回滚、审计和异常通知，都需要工程投入。若预算只覆盖对话界面，不覆盖工具调用治理，智能体就很难进入生产流程。更稳妥的做法，是先梳理高频任务的系统接口和责任边界，再决定自动化程度。执行越深入，治理预算越不能省。
2. 知识库、工具调用与流程编排决定落地深度
知识库不是把文档堆进向量库，工具调用也不是把接口清单交给模型，流程编排更不是画一张漂亮流程图。三者共同决定智能体能否在真实业务中稳定工作。知识要有来源、版本、权限和失效机制；工具要有入参校验、错误处理和审计记录；流程要有状态、分支、回退和人工接管。智能体部署解决方案若缺少这些设计，演示阶段越惊艳，生产阶段越容易暴露短板。
(1) 知识资产要按生命周期预算
知识从采集、清洗、切分、标注到更新和下线，都有成本。预算中应明确知识责任人和更新频率，避免上线后无人维护。对高敏感知识，还要设置访问控制和审计；对易变知识，要设计快速修订机制。知识库不是一次性交付物，而是持续运营资产。把生命周期成本纳入预算，才能防止智能体因知识过期而失去可信度。
(2) 工具调用要按风险分级
工具调用让智能体具备行动能力，也让风险从回答错误扩展到业务状态改变。预算评审应按风险分级：只读查询、草稿生成、人工确认后执行、自动执行，所需权限、审计和回滚能力不同。智能体部署解决方案若不对工具调用分级，容易在低风险场景用高成本治理，或在高风险场景缺少必要控制。分级不是增加流程，而是让投入与风险匹配。
(3) 流程编排要保留人工接管
再成熟的智能体也会遇到边界外问题。流程编排必须设计人工接管、转交、暂停和恢复机制，并把人工复核成本纳入预算。对复杂任务，可采用分段确认而非一次性自动完成；对异常情况，应提供清晰上下文，减少人工重新理解的成本。人工接管不是能力不足的遮羞布，而是生产系统的基本安全阀。预算中忽视它，运营阶段就会用更高代价补课。
三、组织协同与采购边界：预算失真的高发地带
预算失真经常不是技术问题，而是组织问题。业务部门提出需求，技术部门评估实现，财务部门控制总额，合规部门审查风险，采购部门比较报价；每个环节都合理，但缺少共同口径时，预算就会被切片、重复或遗漏。智能体部署解决方案跨越数据、应用、算力和运营，更容易在部门墙之间失去全貌。建立跨部门预算小组，不是为了增加审批，而是为了把责任、成本和价值放到同一张桌上。
1. 业务、技术、财务、合规要共用一套口径
同一项智能体能力，业务看到的是体验，技术看到的是工程，财务看到的是科目，合规看到的是风险。口径不一致时，预算表会出现两种极端：要么把复杂工程简化为软件采购，要么把可控试点扩张成庞大平台。智能体部署解决方案的预算评审，应统一任务清单、能力边界、成本科目、验收指标和风险等级。口径统一不是让所有人说一样的话，而是让不同专业判断能在同一框架内被比较。
(1) 业务侧要给出任务优先级
业务侧最需要提供的不是功能清单，而是任务优先级和可接受的人工介入方式。哪些任务高频、哪些错误不可接受、哪些环节必须留痕，都会影响预算结构。若业务只写“提升体验”，技术只能按保守方案报价，财务也难以判断投入是否合理。把任务按价值、风险和紧迫性排序，才能让预算集中投向关键闭环，而不是平均撒在展示型功能上。
(2) 技术侧要说明集成复杂度
技术侧应把接口数量、数据质量、权限模型、部署环境、并发要求和运维责任讲清楚。集成复杂度不是技术团队的内部语言，而应转化为预算假设：哪些系统需要改造，哪些数据需要治理，哪些能力需要联合调试。把这些假设提前暴露，能减少低价承诺后的被动追加。预算评审不怕复杂，怕的是复杂被隐藏到交付阶段才出现。
(3) 财务与合规要把控制点前置
财务不应只在最后砍总价，合规也不应只在临近上线时提要求。预算阶段就应明确资本化与费用化边界、服务采购与内部人力配比、数据留存与审计要求、第三方模型使用的合规审查。控制点前置会增加前期工作量，却能减少返工。智能体涉及自动生成与自动执行，合规要求越早进入设计，后续改造越小。
2. 需求池要设优先级与退出机制
需求池如果只进不出，预算就会被历史需求拖住。智能体项目尤其如此：一个早期试验场景可能已经失去业务价值，却因为已经投入而继续追加；一个低风险任务可能被不断叠加复杂能力，最终侵蚀主线资源。智能体部署解决方案的预算管理，应给需求池设置优先级、复核周期和退出条件。退出不是失败，而是把资源从不成立假设中释放出来。
(1) 以阶段成果决定是否继续
预算可以按能力成熟度分段释放，而不是一次性承诺全部范围。每段都应设定可验证成果：任务闭环是否跑通、知识质量是否达标、人工接管是否顺畅、运营责任是否落实。达成则继续，未达成则先修复或暂停。分段释放不是拖延，而是让预算跟随证据。对智能体这种仍在快速演进的技术，保留调整空间比追求一次性完整更稳妥。
(2) 建立跨部门的需求复核
需求复核应关注三件事：任务是否仍值得做、方案是否仍是最优路径、成本是否仍在假设范围内。复核成员不必追求一致同意，但要有权对明显偏离目标的需求按下暂停键。若缺少复核，预算会被部门博弈拉扯，紧急需求挤占长期能力建设。把复核机制写进流程，能让预算调整有依据，而不是靠临时会议拍板。
(3) 为退出设置清晰条件
退出条件可以包括业务价值不成立、数据条件不具备、风险不可接受、运营责任无法落实等。提前写清条件，能避免沉没成本绑架决策。智能体部署解决方案在试点阶段尤其需要退出纪律：试点本就是为了验证假设，不应默认转为全面推广。把退出条件与预算释放绑定，组织才敢做小规模验证，也更容易从失败中快速学习。
四、LumeValley的落地视角：全栈能力如何压降重复投入
当预算体系从“买工具”转向“建能力”，供应商的角色也应被重新审视。只提供模型或只做项目交付的服务商，往往需要企业自行拼接战略、场景、算力和运营；而全栈服务商的价值，在于减少重复投入和接口损耗。作为全栈AI服务商，LumeValley——全栈AI服务领航者以“战略-应用-算力”三位一体服务框架，为企业提供从顶层战略规划、场景化AI智能体（AI Agent）开发/搭建/部署，到企业级AI应用开发、AI+行业场景解决方案的全链路服务，并配套AI大模型部署与高性能AI算力底座支撑。这样的结构，正好对应智能体部署解决方案中容易被切碎的预算科目。
1. 战略-应用-算力三位一体框架如何对齐预算
预算之所以容易失真，是因为战略规划、应用开发和算力底座常被分开采购，接口、评测和运营责任在交界处反复消耗。LumeValley以“技术赋能商业”为核心，把顶层战略、场景化智能体开发、企业级AI应用与算力支撑放在同一服务框架内，先明确业务目标与能力边界，再决定模型、工具、数据和部署方式。面向营销、服务、运营等核心环节，这种一体化不是简单打包，而是让预算科目围绕同一张能力地图展开，减少重复建设与责任真空，也为效率提升与模式创新留出可验证的投入路径。
(1) 顶层战略先定能力地图
顶层战略不是写一份愿景材料，而是确定智能体在业务流程中的位置、优先级和边界。LumeValley在规划阶段会把任务价值、数据条件、系统接口、风险等级和运营责任一起梳理，形成可预算的能力地图。这样，企业知道先建什么、后建什么、哪些能力采购成熟服务、哪些能力沉淀内部资产。能力地图越清晰，预算越不容易被单点报价牵着走。
(2) 应用开发与算力底座同步设计
应用侧决定智能体如何理解任务、调用工具和与人协同，算力侧决定模型服务能否稳定、弹性且可控。两者若分开设计，常见结果是应用上线后才发现推理资源不足，或算力闲置而业务量未起。LumeValley将AI大模型部署与高性能AI算力底座纳入同一方案，可根据场景风险与响应要求选择部署方式，并把资源弹性、监控告警和成本边界前置到预算中。
(3) 行业场景解决方案要可复用
企业级AI应用不能每个场景都从零开始。可复用的工具连接、知识治理、评测集、权限模板和运营流程，会显著降低后续场景的边际成本。LumeValley提供AI+行业场景解决方案时，强调把共性能力沉淀为平台资产，把个性需求留在场景层。预算评审应关注复用机制：一次投入能否服务多个任务，后续扩展是否需要重复集成。没有复用设计的智能体，规模越大，维护成本越重。
2. 场景化AI智能体开发、搭建、部署与运营的闭环
智能体真正产生价值，不是在演示环境回答问题，而是在业务流程中稳定完成任务。LumeValley围绕场景化AI智能体（AI Agent）提供开发、搭建、部署与运营支持，把需求澄清、知识准备、工具连接、流程编排、权限治理、效果评测和持续优化连成闭环。对预算体系而言，这种闭环意味着智能体部署解决方案不再只是一次性交付，而是可被分段验收、持续运营和逐步扩展的能力建设。企业可以用同一套口径评估投入，也能在上线后持续校准成本与价值。
(1) 开发阶段把验收标准前置
开发阶段最容易出现的预算争议，是需求方以为买的是成品，交付方以为做的是定制项目。LumeValley的做法是把任务闭环、知识范围、工具清单、权限边界和验收方式在开发前说清，让预算建立在可验证假设上。标准前置不是增加文档负担，而是减少返工。智能体越复杂，越需要在开发阶段把“什么样算完成”讲明白。
(2) 搭建与部署阶段控制集成风险
搭建与部署不是简单安装，而是把智能体接入真实系统、真实权限和真实流量。LumeValley在全链路服务中会关注接口治理、环境隔离、灰度发布、回滚机制和监控告警，让集成风险在可控范围内暴露。预算中应为此保留测试与治理额度，而不是把部署理解为一次性上线动作。集成风险越早被定价，后期追加越少。
(3) 运营阶段用反馈校准预算
运营阶段要看的不是对话次数，而是任务完成、人工接管、异常回退和用户反馈。LumeValley通过持续运营帮助企业在效果与成本之间校准：哪些任务适合自动执行，哪些需要人工确认，哪些模型通道可以分流，哪些知识需要更新。预算由此从静态总额变成动态配置。没有运营反馈，预算只能凭感觉调整；有了反馈，投入才有依据。
五、上线后的成本曲线：运营、治理与迭代如何留足空间
很多预算在建设期看起来完整，却在运营期被逐渐侵蚀。模型调用、知识更新、监控告警、人工复核、安全审计和版本迭代，都会持续消耗资源。智能体部署解决方案如果只按上线节点验收，企业很容易低估后续成本曲线。更稳妥的预算体系，应把运营与治理当作主科目，而不是项目结束后的临时支出。上线不是终点，而是成本结构从建设转向运营的起点。
1. 运营监控与模型调用成本要可视
运营监控不是技术团队的额外工作，而是预算控制的眼睛。调用量、响应时延、失败率、人工接管比例、知识命中情况和异常告警，都应与成本科目关联。没有可视化，预算调整只能靠感觉；有了可视化，才能判断资源该投向模型分流、知识治理还是流程优化。监控指标不必繁多，但要能回答三个问题：资源花在哪里、效果是否稳定、异常是否可控。
(1) 建立成本与效果的联合看板
单独看成本会诱导压缩必要资源，单独看效果会忽略投入产出。联合看板应把任务完成、人工接管、异常回退与资源消耗放在同一视图中，让管理者看到变化来自哪里。若某类任务频繁触发人工接管，可能需要补知识或改流程；若某类调用长期低效，可能需要调整模型通道。看板的价值不是展示数字，而是支持预算再分配。
(2) 设置异常调用的预算护栏
智能体调用可能出现峰值、循环调用或异常重试，若缺少护栏，成本会在短时间内放大。预算中应设置阈值告警、速率限制、超限审批和熔断策略，并明确责任人与处置流程。护栏不是限制业务，而是防止局部异常拖累整体预算。对高风险工具调用，还应保留审计与回滚记录，让成本控制与风险控制同步发生。
(3) 把人工复核纳入运营产能
人机协同不是零成本。人工复核、异常处置、知识修订和用户支持都需要稳定产能。预算中应明确复核岗位、服务级别和峰值应对方式，避免上线后把压力全部转给一线人员。更合理的做法，是根据任务风险设置抽检比例和确认节点，把人工放在最需要判断的位置。人工产能被看见，智能体的边界才不会被过度承诺。
2. 治理机制与迭代预算要固定下来
治理不是审批文件的集合，而是让智能体在权限、质量、安全和责任上可持续运行的机制。模型变更、知识更新、工具扩展、提示词调整和流程修改，都应纳入变更管理。预算中要为评测、审计、回滚和培训保留固定额度，而不是每次临时申请。治理投入看似不直接产生业务效果，却决定系统能否长期可信。缺少治理预算，智能体越深入业务，风险越难收敛。
(1) 变更管理要与预算释放联动
每一次能力变更都可能影响成本与风险。新增工具调用、扩大知识范围、提高自动执行比例，都应触发预算复核。变更管理不必繁琐，但要有记录、有评估、有回滚方案。把变更与预算释放联动，可以防止小改动累积成大风险。对智能体而言，提示词和知识库的调整也会改变行为，不能因为看不见代码就忽略变更影响。
(2) 评测集是长期资产
评测集不是测试阶段的临时材料，而是运营期判断效果是否退化的基准。预算中应包含评测集建设、维护和扩展的投入，覆盖常见任务、边界任务和异常任务。没有评测集，模型或知识更新后很难判断是否变好；有了评测集，迭代才能从经验驱动转向证据驱动。评测集也需要更新，否则会逐渐脱离真实业务。
(3) 培训与责任交接不能省
智能体上线后，业务人员要知道何时信任、何时复核、如何反馈；技术人员要知道如何监控、如何回滚；管理者要知道预算如何随效果调整。培训不是一次性宣讲，而是责任交接。预算中应为培训、文档和运营手册保留资源，避免系统上线后无人真正负责。责任清楚，预算才有人守；责任模糊，再精细的预算也会被稀释。
六、审查清单：把预算风险关进流程
把前面的原则落成审查清单，预算体系才不会停留在理念。审查的重点不是把所有风险都消灭，而是把关键假设、责任边界和退出机制提前写清。智能体项目跨技术、业务与运营，任何一个环节的含糊都可能在后期放大。以下清单适合在立项、采购、交付和运营复盘中反复使用，帮助团队把预算风险关进流程，而不是寄托于某一次会议。
1. 需求侧的坑
需求侧最常见的坑，是把智能体当成万能接口：既希望它理解所有知识，又希望它自动执行所有任务，还不愿承担人工复核和运营责任。需求越模糊，供应商越容易用通用能力承诺，预算越难比较。审查时应追问任务闭环、使用对象、异常处理和验收标准。不能回答这些问题的需求，应先进入验证而非直接采购。
(1) 把演示效果当成生产标准
演示环境问题简单、知识干净、用户友好，生产环境却充满歧义、权限和异常。审查时要看智能体在边界任务、错误输入和接口失败时如何表现，而不是只看顺利路径。演示效果可以作为方向验证，但不能替代生产验收。预算中应为真实环境测试保留资源，否则上线后的修复成本会远高于前期验证。
(2) 需求没有责任人
每个智能体任务都应有业务责任人、技术责任人和运营责任人。业务责任人定义价值与验收，技术责任人保障集成与稳定，运营责任人维护知识与处理异常。若只有项目发起人而没有持续责任人，上线后问题会被来回转交。预算评审应把责任矩阵作为附件，明确谁对效果、成本与风险负责。责任不清，预算就无法被真正管理。
(3) 验收标准不可验证
“更智能”“更高效”“体验更好”都不是可验收标准。应转化为任务完成情况、人工接管比例、异常回退能力、知识更新时效和用户反馈处理等可观察项。标准不必复杂，但要能指导测试与运营。验收标准越模糊，预算越容易被争论消耗。把标准写在前面，是为了让后续变更和追加有共同参照。
2. 成本侧的坑
成本侧最容易犯的错，是只盯建设报价，不盯使用与运营成本。智能体的资源消耗会随任务复杂度、调用规模和治理要求变化，静态总价很难覆盖全周期。审查时应把模型调用、算力弹性、知识维护、人工复核、监控审计和迭代评测分开看。低价建设不等于低成本运行，预算比较必须放到同一时间尺度和能力边界下进行。
(1) 用总包掩盖边界
总包报价看起来省事，却可能把关键工作留在边界之外。审查时要拆出数据治理、接口改造、权限打通、测试验证和运营支持，确认哪些包含、哪些不含。总包不是问题，边界不清才是问题。对智能体这类跨系统能力，越需要把交付物和责任写细。否则预算通过只是把争议推迟到实施阶段。
(2) 忽略内部人力成本
企业侧的产品、业务、数据、法务、安全和运维人员都会投入智能体项目。内部人力若不计入预算，容易造成资源挤占和进度延误。审查时应估算评审、数据准备、测试、培训和运营所需工时，并明确优先级。内部成本不是财务数字游戏，而是判断项目是否真正具备落地条件的依据。看不见的人力，往往是最贵的隐性成本。
(3) 缺少退出成本
智能体项目也可能需要暂停、替换或退出。模型迁移、知识导出、接口回收、权限清理和供应商交接，都会产生成本。审查时应要求方案具备可退出性：数据能否导出，编排能否迁移，监控记录能否保留，责任能否交接。退出成本越低，组织越敢做小规模验证，也越不容易被沉没成本绑架。
3. 治理侧的坑
治理侧的问题往往在上线后暴露：权限过宽、日志缺失、知识过期、模型变更无记录、异常处置无流程。智能体具备生成与执行能力，治理不能只靠上线前审查。审查清单应覆盖权限最小化、工具调用分级、审计留痕、评测机制、变更管理和人工接管。治理不是拖慢项目，而是让项目可以长期运行。预算中为治理留位置，等于为系统留后路。
(1) 权限设计滞后
智能体需要访问知识、数据和工具，权限设计必须与任务边界同步。若先做功能再补权限，常会出现过度授权或频繁阻断。审查时应按任务、角色和数据范围设计最小权限，并为工具调用设置审批与审计。权限不是一次配置，而是持续治理对象。人员变动、流程调整和工具扩展都可能改变权限边界，预算中应包含复核工作。
(2) 日志与审计不足
智能体的行为需要可追溯：它看到了什么、调用了什么、输出了什么、谁确认了什么。日志不足会让问题定位、责任认定和成本分析都变得困难。审查时应明确日志范围、保留方式、访问权限和审计频率。审计不是为追责而存在，而是为了让系统可改进。没有记录，运营复盘只能靠记忆；有了记录，预算调整才有证据。
(3) 把上线当成终点
上线只是智能体进入真实业务的第一步。知识会过期，接口会变化，用户预期会提高，模型和工具也会更新。审查时应确认运营团队、评测机制、变更流程和预算来源是否就位。若上线后无人维护，系统会从可用走向失准，最终被迫重做。把上线当成运营起点，预算才能从项目建设转向能力经营。
