企业智能体落地需要哪些外围工程

企业内部的 AI Agent，难点往往在模型周围：它能读哪些数据、什么信息可以发出去、操作如何追溯，以及怎样接入已有系统。作者把这层运行与管理机制称为 harness，并列出了他们为企业搭建内部 AI 系统时采用的做法。

这份清单最有价值的地方，是指出了两个容易低估的问题：员工已有的权限，交给 Agent 后可能产生更大的风险；公司文档里的标准答案，也可能早就落后于实际工作。

Agent 继承员工权限，为什么还不够安全

作者的权限原则很明确：Agent 使用发起任务的那名员工的访问权限，看不到员工无权查看的内容。运行环境封闭，对外流量经过过滤，客户系统的密码和密钥加密保存。

这些措施解决了基本的访问边界，却没有解决访问速度带来的变化。

员工通常逐份阅读文档，Agent 则可能在几分钟内遍历权限范围内的全部内容。同一套权限，在人工操作下暴露有限，交给自动化系统后，数据收集的规模会迅速扩大。

另一个问题来自输入内容。作者提醒，Agent 读到的每封邮件，都可能包含试图指挥它的文字。这涉及提示注入（prompt injection）：本应作为资料阅读的内容，可能被模型当成执行指令。

继承员工权限只是起点，不能据此认定 Agent 已经足够安全。

原文没有展开如何识别恶意指令、限制批量读取，或者约束高风险操作。因此，这部分提供了风险判断，但还不是完整的防护方案。

数据发给外部模型前，要先过哪道关

作者把个人数据检查放在客户自己的环境内完成。税务识别号、IBAN 和银行卡号通过校验和验证，姓名则由独立检测器识别。

请求发送给外部模型之前，检测到的值会被占位符替换；模型生成最终回复后，再把原值还原。占位符与原始数据之间的映射表也会加密保存。如果脱敏失败，请求就不发送。

这里有两个关键设计：检查发生在数据离开客户环境之前，而且失败会阻断请求。

但还需要区分「处理失败」和「没有检测出来」。原文没有说明检测器的覆盖率，也没有交代地址、自由文本中的身份线索等信息如何处理。不能仅凭这套流程，就认定所有敏感信息都不会外泄。

模型部署也围绕任务和数据做选择：可以使用外部提供商、租用的算力，或者客户自有硬件。大型模型负责推理和分析，小型本地模型负责大批量处理与敏感数据任务。新模型发布后，由客户决定是否切换。

这是一种按任务分配模型的思路。原文没有给出具体模型名、效果对比或成本数据，无法据此判断大小模型的分工在什么任务上最划算。

接入业务系统之后，为什么日志和文档都要管

作者的 harness 会连接企业已有的 SAP、NetSuite、QuickBooks、邮件和 CRM。不同客户使用各自的模块，底层共享核心能力。推进方式是先做一个模块试点，衡量结果，再扩展到其他部门。

日志覆盖登录和 AI 请求，记录谁发起请求、哪个模型回答，以及花费多少。这能为追溯使用情况和核算成本提供基础。不过，原文没有说明是否记录工具调用、业务数据修改和操作结果，不能把它理解成完整的执行审计。

比连接器更隐蔽的问题，是知识源本身。

助手依据文档回答，但文档可能落后于实际工作。团队几年前已经通过非正式方式修正的流程，如果没有同步到文档，就可能被 AI 重新包装成「官方答案」。

能从文档找到依据，不等于答案符合当前业务。

因此，接入知识库还需要处理资料有效性。原文明确指出了这个成本，却没有提供文档更新、冲突裁决或失效管理的具体办法。

我的判断

这套思路说得对的地方，是把权限、数据出口、模型选择、日志和业务接入放在一起考虑。对于企业内部 Agent，这些环节决定了系统能否进入真实工作流程。

其中，脱敏失败就阻断请求，以及先试点再扩展，都是边界清楚、容易转化为实施要求的做法。

但这篇文章更接近供应方的架构清单。作者描述了他们采用什么，没有给出测试方法、检测准确率、试点收益或安全事件数据。它能作为方案评审的提纲，效果层面的说法仍属于经验之谈。

与所有请求统一使用外部大模型相比，按任务分配模型增加了选择空间，也带来了路由、部署和维护工作。与单纯让助手检索文档相比，这套方案考虑得更广，但仍未回答权限放大、提示注入和过期知识如何被可靠地控制。

能拿来做什么

• 给内部 AI 助手接权限时，把任务发起人的身份带到后端访问检查中，并单独评估 Agent 批量读取数据后的影响。
• 在 Node 服务调用外部模型前设置统一的数据检查入口，明确占位替换、映射加密、回复还原和失败阻断的处理规则。
• 为 AI 请求记录发起人、所用模型和成本，让试点阶段的使用情况能够被追溯和核算。
• 先选择一个业务模块试点，同时核对它依赖的文档是否仍然有效，再根据测量结果决定是否扩展。