Agent 越多，企业越需要一个统一控制层
Salesforce 近期提出 Enterprise AI Harness 和 AI Control Plane 的概念，关注点不是再发布一个单独的聊天助手，而是如何在企业里统一管理越来越多的模型、Agent 和自动化动作。这个方向很有代表性，因为企业真正遇到的问题已经从“要不要用 AI”变成“公司里这么多 AI 到底谁负责、能访问什么、效果如何、成本多少”。
当每个部门都自行接入模型时，短期看起来效率很高，长期却容易出现重复采购、权限混乱、数据孤岛和责任不清。销售团队有自己的 Agent，客服团队有自己的 Agent，财务和研发又分别接入不同平台。如果没有共同的身份、策略、评估和生命周期管理，企业很难回答一个简单问题：现在到底有哪些 AI 在替我们做事？
企业 AI Harness 解决的是什么
可以把 AI Harness 理解成 Agent 的基础设施层。它不一定替代具体业务 Agent，而是为它们提供共享能力：理解企业上下文、接入身份和权限、调用模型与工具、执行策略、观察行为、评估结果和控制成本。
这样的设计与传统软件平台很像。企业不会让每个应用自己实现账号、审计、支付和权限，同样也不应该让每个 Agent 自己决定谁能访问数据、什么动作需要审批以及日志保存多久。统一控制层可以减少重复建设，让新的 Agent 更容易复用现有的安全和治理能力。
第一件事：建立 Agent 资产目录
治理的起点不是写一份长政策，而是知道资产在哪里。企业需要登记每个 Agent 的名称、负责人、服务部门、使用的模型、连接的工具、能访问的数据、风险等级、上线时间和当前状态。
一个 Agent 可能已经停止使用，但仍然保留 API 密钥和数据库权限；另一个 Agent 可能被多个部门调用，却没有明确的产品负责人。没有目录就无法清理、评估和追责。目录还应该记录版本和变更历史，知道最近谁修改了提示词、工具或权限。
对小企业而言，不需要先购买复杂平台，可以从一张表开始。只要把 Agent、数据、工具、负责人和风险写清楚，就能发现很多隐藏问题。随着使用量增加，再把登记过程做成后台表单和自动检查。
第二件事：统一身份与政策
Agent 代表谁做事，是企业治理的核心。系统要区分发起请求的用户、执行任务的 Agent 和被调用的工具。不能因为模型能够生成一个用户名，就把这个字段当成可信身份。
每个动作都要经过服务端权限判断。员工能够查看什么资料，Agent 能够调用什么工具，什么时候必须重新授权，都应该由身份系统和策略引擎执行。高风险动作需要更多条件，例如二次认证、负责人审批、金额上限或工作时间限制。
政策也应该能被机器检查。例如“外部邮件必须人工批准”“客户数据不能发送给未授权供应商”“批量写入超过100条必须分批确认”。把规则写成可执行条件，比只放在培训文档里更可靠。
第三件事：评估 Agent 的工作结果
传统软件通常看可用性和错误率，Agent 还要看任务是否真正完成。它是否找到了正确资料？是否按要求格式输出？是否多次重复调用？是否让员工花更多时间修改？是否在不确定时请求帮助？
不同 Agent 要有不同的评分标准。客服 Agent 需要关注解决率、转人工率和事实准确性；销售 Agent 需要关注线索字段完整度、跟进建议和 CRM 写入正确性；财务 Agent 需要关注数据口径、权限和审计；代码 Agent 需要关注测试、安全扫描和变更范围。
统一平台可以提供评测框架，但不能用一个分数覆盖所有业务。企业应当为每个重要 Agent 建立一组真实、脱敏、持续更新的样本，并在版本变化后回归测试。
第四件事：观察成本和行为
AI 成本不会只出现在模型账单里。长上下文、重复检索、工具调用、执行环境、存储和人工审核，都会影响单任务成本。管理者需要看到每个 Agent 每天完成多少任务、平均调用多少次、失败多少次、人工接管多少次，以及每个任务为企业创造了什么结果。
如果一个 Agent 使用量上升，但效率没有改善，可能是在自动化“无价值的忙碌”。如果某个 Agent 的调用次数突然增加，可能是提示词循环、工具错误或权限配置有问题。观测不仅是为了报表，也是为了快速定位系统行为。
为什么企业不应一开始就追求全自动
全自动听起来很有吸引力，但企业流程通常涉及例外、责任和客户关系。更稳妥的路线是分级自治。只读查询和内部摘要可以高自动化；生成草稿和创建待办可以自动完成，但需要抽查；修改生产记录、发送外部消息、付款和改变权限则要人工批准。
控制平面不应把治理做成处处阻碍。好的治理会把高风险动作挡住，把低风险动作放行，并让审批人看到足够证据。这样团队反而更敢于扩展 Agent，因为他们知道出了问题可以追踪和回滚。
对 FDE 和企业服务的机会
很多企业缺的不是一个模型，而是统一梳理 AI 资产的能力。FDE 可以帮助客户盘点流程、选择优先级、设计权限、建立评测、打通工具和培训用户。这样的服务比单纯卖一个聊天机器人更有长期价值。
服务交付可以分成几步：第一，做 AI 资产和数据地图；第二，挑一个低风险流程做试点；第三，建立身份、日志和指标；第四，扩展到更多工具和团队；第五，把成功案例沉淀为模板。客户最终得到的是一套可以继续扩展的能力，而不只是一个 Demo。
对网站后台建设的启发
一个内容平台本身也需要类似的控制平面。采集、改写、图片上传、SEO检查、发布和客户下载，都是不同的动作。每一步都应该有状态、负责人、来源和日志。后台不应该只显示“成功或失败”，还要能回答“谁在何时通过什么方式改了什么”。
这正是客户管理功能的价值：用户下载工具时留下邮箱，验证完成后记录工具、来源和时间；后台可以看到客户是否再次访问、下载了什么、是否需要服务跟进。内容、工具和企业服务因此能够连接起来。
总结
Salesforce 提出的企业 AI Harness 和 Control Plane 代表一个全球趋势：当 Agent 从试验变成组织基础设施，身份、政策、生命周期、评估、观测和成本就不能分散在各个项目里。
对个人用户，治理意味着更清楚的授权和更少的误操作；对企业，治理意味着可控扩张；对 FDE 和服务平台，治理本身就是新的交付能力。Agent 越多，统一控制层越重要。
读者可以马上做的三件事
第一，把文章中的趋势放回自己的工作场景，不要因为一个新闻标题就立刻更换工具或购买服务。先写下你最想解决的一个问题，明确输入、输出、成功标准和不能交给 AI 的部分。第二，准备少量真实且脱敏的样本，比较答案质量、完成时间、人工修改和成本。只有经过自己的数据验证，全球新闻里的能力描述才会变成对你有用的判断。第三，把结果记录下来，过一周再复盘：系统是否真的节省时间，错误是否集中在某一类，用户是否愿意继续使用。这样的闭环比收藏更多模型发布消息更有价值。
对于企业团队，还应该保留来源和版本信息。模型、价格、权限和产品功能都可能变化，文章中的事实适合帮助你建立方向，不应替代正式合同、供应商文档和安全评审。对于个人用户，最重要的是保护隐私、核对来源和保持可撤销性；对于内容运营者，最重要的是把新闻转化为清楚、诚实、能执行的下一步。