作者｜沙丘智库研究团队
来源｜沙丘社区（www.shaqiu.cn）
我们精选了上周沙丘智库发布的13份研究报告，涵盖AI编程、智能体治理、企业本体、交付模式与创新实践。本文按成本管理、工具选型、业务落地和组织能力四个主题，梳理这些报告的主要发现、案例与建议。
01
AI用起来了，账应该怎么算？
▎1/ 海外AI Coding Agent产品定价研究：Claude Code、Codex、Cursor和GitHub Copilot
采购时比较的是每人每月多少钱，真正使用后，费用却会受到模型选择、输入输出Token、共享额度和智能体运行强度的共同影响。
Claude Code、Codex、Cursor和GitHub Copilot的价格与使用权益各有安排，比较时还得看基础费用包含多少额度、超额怎样计费、积分何时到期，以及是否另收平台费用。共享额度耗尽之后，正在进行的任务能否继续，也取决于具体产品和预算设置。
对于企业采购，消费承诺和续约条件同样影响这笔账。工作量增加后，费用怎样增长；模型或使用方式改变后，合同是否允许调整，都应在签约前弄清楚。
▎2/ AI Coding成本进入精细化治理：软件工程负责人如何优化成本？
同样一个账号，有人偶尔用来解释代码，有人每天在开发中使用，还有人让智能体持续执行多步骤任务。按统一的人均额度分配预算，很难照顾这些差异。
这份报告从Google的定价与成本管理调整谈起，讨论了软件工程负责人为什么要参与预算。采购部门了解价格与合同，工程团队更了解任务的用量需求与业务价值；平台团队则负责把用量、异常和额度记录下来。三方使用同一套数据，才能随着实际需求调整预算。
承诺用量换折扣，也要先验证团队能否持续达到门槛。如果实际消耗不足，闲置额度和过多承诺可能抵消折扣带来的节省。
▎3/ AI Coding Agent如何提升投资回报：用CRAFT框架量化开发者行为
还有一部分费用，藏在开发者的使用习惯里。反复粘贴大文件、让同一会话不断膨胀，都会增加消耗。仅凭Token用量，很难区分是在处理复杂任务，还是交互方式出了问题。
CRAFT从上下文、工具覆盖、自主性、工作流和吞吐量五个维度观察这些行为。例如，调用AI之前是否说清了任务边界，提供的信息是否适量，子任务是否合理委派，执行结果是否正确。团队可以据此找到需要辅导的具体习惯，而不只是要求大家少用Token。
这套方法有一条明确边界：CRAFT用于成长辅导，不能直接用于正式绩效评价。综合分也不是财务ROI。会话更多、输出更快，都要结合质量和成本来看；否则，表面上增加的产出，可能还要花更多时间返工。
02
工具选定之后，供应关系仍在变化
▎4/ AI Coding Agent走向垂直整合：OpenAI断供Cursor后的企业策略
2026年8月28日，OpenAI宣布计划终止通过Cursor提供模型的协议，拟定停止日期为11月12日。对依赖这些模型的团队来说，今天还能使用，不代表原有接入方式会一直保留。
随着模型厂商自建编程工具、工具厂商发展自有模型，接入条件、产品优化和费用都可能改变。选型也因此不能只比较模型本身，还要一起测试Harness——它负责提供上下文、调用工具、执行任务和验证结果，直接影响模型在实际开发中的表现。
应对变化，首先要查清哪些任务依赖特定模型，再验证替代方案能否满足要求。企业上下文、编码标准、规则文件和验证门槛，则应尽量保持可移植。即使改用自己的API密钥，也要重新核对功能、性能、路由和技术支持，不能默认与原生接入相同。
▎5/ 英伟达收购Hugging Face：开源战略背后的开发者入口与算力护城河
英伟达9月3日宣布拟收购Hugging Face。这项尚未完成交割的交易，把模型分发平台的战略价值摆到了台前。开发者与智能体选择、拉取和部署哪些模型，会形成持续的需求记录；掌握这些信息，有助于判断模型、芯片和基础设施的投入方向。
开放模型给企业带来更多成本与部署选择，平台所有权变化也带来了新的不确定性。报告关注的一种风险是：如果硬件无关工具的投入下降，使用非英伟达硬件的企业可能承担更多工程工作和迁移成本。这仍是需要观察的情景，不能据此认定平台已经失去中立性。
除了关注许可和价格，企业还应了解自己的部署依赖，保留跨硬件迁移的选择，并记录自身的模型使用情况，用于成本管理和后续选型。
▎6/ 企业AI Coding Agent选型指南：从多供应商组合到价值验证
选型的第一步，是找准团队卡在哪里。遗留代码难以理解、测试不足、代码审查等待过久，对应的评估任务并不相同。只测试生成新代码的速度，很容易漏掉实际瓶颈。
指南将选型分为四步：定义预期价值；按部署、数据主权和监管要求筛选；评估开发模式与用例；通过限时价值验证确认产品或组合。试点应使用企业正式可采购和部署的版本、模型与网络环境。
报告建议以一款默认日常工具为基础，按明确缺口增加最多两款补充产品。增加产品要说明用途，也要计入额外成本。试点除了记录任务完成时间，还应观察缺陷、返工、人工审查负担和开发者体验。节省的工时能否转化为更多交付或实际支出减少，需要另行验证，不能直接算成现金收益。
03
AI进入业务现场，需要补齐哪些能力？
▎7/ 企业本体研究报告：Agent业务语义层的建设与落地
Agent查询到备选仓有180件库存，建议调拨100件。但其中60件已预留、30件属于安全库存，实际可调拨量只有90件。这是本体报告中用来说明业务语义问题的示例。
Agent虽然查到了数字，却没有正确使用“可调拨量”的口径，也没有把物料映射与审批规则纳入判断。给它更多材料，仍然不能代替企业决定哪个定义有效、以哪个系统为准、当前用户有权做什么。
对象错认、指标歧义、关系缺失、状态过期、规则失真和行动越权，是报告归纳的六类故障。它们看起来都像“AI答错了”，修复办法却不同。
企业本体并非所有Agent项目的必选项。找不到材料应优先改善RAG，指标冲突先统一口径，对象重复先检查主数据与身份映射。只有任务需要跨系统理解对象关系、执行稳定规则或连接受控行动时，本体才可能成为必要能力。
只读建议能够满足业务要求时，可以停在这里。涉及修改订单、库存或资金状态的任务，则必须检查当前状态、权限和审批条件，记录执行过程，并为失败后的恢复或人工处理留下路径。
▎8/ 企业如何建立AI智能体胜任力：从模型能力到可治理数字劳动力
同样的问题也出现在财务工作中。报告以发票异常处理为例：Agent要掌握付款政策、供应商条款、采购订单和历史异常，才能判断差异属于常规问题，还是应交给人工审核。这项工作还涉及调取记录、比较订单和触发流程；哪些可以自行处理、哪些必须审批，都应有明确规则，并留下审计记录。
智能体是否“胜任”，要看它能否在这些具体要求下完成工作。模型提供推理基础，技能封装操作方法，企业知识提供判断依据，运行支撑工程负责系统集成、编排、防护、监控和评估。这些部分要一起配合，才能支撑稳定的业务执行。
起步时，可以先为一两个重点用例写清所需知识、技能、控制措施和验收标准。现有知识库是否准确且可访问，专家经验能否整理出来，应用接口能否支撑操作，都应在试点中逐项验证，再决定是否扩展。
▎9/ 人机协同绩效管理重构：智能体时代如何明确责任与评价标准
一项由人和AI共同完成的工作出了错，问题可能来自员工判断，也可能来自模型、数据或流程设计。管理者如果只看最终交付，容易把系统问题归给个人，反复出现的AI故障也可能得不到修正。
这要求CIO与人力资源负责人共同调整评价办法。智能体是否可靠、是否按业务意图行动、何时交由人工处理，应有人持续跟踪。版本历史、审批记录、员工对AI输出的修改和返工记录，则能帮助管理者还原工作过程，判断问题出在哪里。
工作记录不应演变成员工监控，指标也不能机械解读。交由人工处理的次数减少，可能是系统更可靠，也可能只是员工不再报告问题；返工减少，则要检查输出质量是否同步提高。弄清这些差别，管理者才能有针对性地辅导员工、修正系统与流程。
04
从做成一个项目，到留下可复用的能力
▎10/ Palantir交付模式研究：竞争优势、运行机制与中国企业启示
在复杂的企业AI项目中，数据接入、规则梳理和跨部门协调，往往要靠大量现场工作才能完成。软件功能齐备，并不意味着客户已经具备使用它的条件。
Palantir让前线部署工程师（FDE）直接进入业务现场，与客户一起理解问题、处理数据和构建应用。项目中反复出现的需求和方法，再被整理为平台功能，供后续项目使用。现场服务由此也参与了产品改进。
如果每个新客户都依赖更多定制代码和驻场人员，这种做法很难扩大规模。它能否持续，既取决于平台复用，也取决于客户能否逐步接手。
知识转移应提前纳入交付安排。外部团队完成早期探索后，客户逐步接手日常运营与标准场景，专家才有余力处理新的复杂问题。这种模式也有适用范围：标准报表或简单集成，未必值得投入高成本的复合型团队。
▎11/ AI创新的分水岭：领先企业靠执行，而非更强技术
“解决数据分散”，听起来是一个合理的项目目标。但数据分散到底拖慢了哪项决策，增加了哪种风险，又怎样影响客户？这些后果没有说清楚，团队就难以判断系统上线后是否解决了问题。
报告归纳的四项原则，都围绕实际工作展开：从已经造成可测量影响的瓶颈出发，重新安排工作流程，在设计时确定治理与责任要求，再把成功做法用于其他项目。
其中，超聚变的报价配置智能体把供应、利润率和技术约束直接放进报价流程，让自动化提速的同时，报价方案仍能满足履约条件。判断这类项目的效果，就应看流程是否按要求改变，以及改变后带来了什么业务结果。
▎12/ AI创新进入规模化阶段：从可复用平台到智能体工作流的五大趋势
一个AI项目做成了，下一个却仍要重新接数据、建评估、做治理，重复投入就会拖慢后续应用。
Huntington National Bank在报告中的做法，是把RAG、评估和可观测性做成共享服务，团队按场景组合使用，风险与安全评审也可以复用。这样，新的解决方案能够从已有基础上开始。
这对应报告所讨论的可复用平台趋势。另外四个变化是智能体开始编排工作流，系统利用实时数据完成感知、决策和行动，治理要求进入架构设计，以及自动化更深入地参与决策。评价也随之具体起来：哪项决策发生了变化，谁采取了不同动作，延迟减少了多少，业务结果是否改善。
因此，项目团队还要说明哪些组件和规则可以共享、谁负责维护。后续项目能少做多少重复工作，是检验平台建设是否有效的一项实际依据。
▎13/ AI价值不止于效率：高增长企业如何提升质量与市场决策
自动化增加了，业务表现未必随之改善。调用次数和节省时间反映了使用情况，评价效果时，还要核对工作是否更准确、更一致，重大错误是否减少。
报告引用的调研中，高增长企业与低增长、零增长或负增长企业，在多数AI应用场景上的使用比例差异并不显著。唯一达到统计显著水平的差异出现在“质量控制与监测”。这不能证明AI带来了更高增长，但提供了一个值得关注的方向：质量保障可能比单纯增加自动化更有区分度。
例如，进入一个新市场，往往伴随招聘、库存和营销预算等投入。AI可以在作出承诺前，帮助团队比较市场、客户与进入方案，找出需要验证的假设，再结合当地知识、小规模测试和人的判断作决定。等到资源已经投下去，AI通常只能帮助加快后续执行，调整方向的空间已经小了。
05
结语
精选的13份报告，关注的是企业开始使用AI之后的一系列实际问题。模型和工具之外，日常使用怎样影响成本，业务规则如何进入系统，员工与智能体怎样分工，都会影响项目最终的效果。这些工作也需要工程、业务和管理团队一起完成。
一个项目留下的知识、规则、组件和经验，能被后续团队继续使用，前期投入才有机会发挥更长久的作用。企业对AI的判断，也会在实际交付中变得更清楚：哪些做法改善了质量和效率，哪些成本值得承担，哪些应用还不适合扩大。
更多AI研究内容可前往【沙丘智库小程序】搜索查阅