昨天，接到一单 2000 块的企业咨询，客户已经把 Agent 用了起来，可一进真实业务，问题一大堆：企业 Agent 到底该怎么落地，Harness 又能做到什么程度？
这个问题没法只靠换一个更强的模型回答。
这涉及到我给企业交付 Agent 最核心的两个环节：一个指向权限管理，一个指向证据门禁，今天分享给大家。
为什么企业不能只看模型能力#
先回到一个很简单的问题：企业为什么敢让员工登录 CRM，却不敢把管理员账号直接交给一个新来的实习生？
因为实习生会干坏事？并不是！
账号能看到什么、能改什么、出了问题能不能追到人，这些边界原本就属于企业管理。换成 Agent 以后，边界不会自动消失，反而更容易被忽略。模型没有公司的职位，也不会天然理解一笔退款和查一条订单之间的风险差别。
第二个问题同样简单：一名员工说“本月业绩预计增长 20%”，管理层通常会继续问，这个数字从哪来？是目标，是根据当前进度算出来的，还是已经在财务系统里确认过？AI 把句子写得再顺，也不能替这 20% 补上证据。
这就是 Harness 在企业里的基本作用。它不只负责让模型调用工具，还要把企业原本散落在制度、账号、审批、经验和责任人脑中的规则，变成 AI 运行时必须遵守的边界。
从第一性原理看，企业 Agent 带来的风险可以先分成两类。
一类是行动风险。它读了不该读的数据，修改了不该修改的客户信息，发出一封不该发送的邮件，或者在没有批准的情况下执行退款。
另一类是结论风险。它拿到了过期数据，把目标写成结果，把预测写成事实，或者在工具调用失败后仍然宣布任务完成。
权限管理限制 Agent 能造成多大的影响，证据门禁决定它的结果能走多远。
完整的 Harness 当然还会处理上下文、状态、重试、成本、日志和人工接管。本文不打算把这些名词全部摊开。对于企业是否敢把 Agent 放进业务，权限和证据是最值得先讲透的两条线。
用一份自动经营日报，把两道门讲清楚#
假设一家公司准备做一个经营日报 Agent。每天早上 9 点，它自动读取 CRM、订单库、客服工单和预算目标，整理出昨天的成交额、转化率、客户投诉和月底预测，然后把日报发到管理群。
这个例子是为了说明方法，不对应某个具体客户。它看起来并不复杂，甚至比很多企业想做的 Agent 简单得多。真正开始设计，问题很快就会冒出来。
它用谁的账号登录？能不能看到全部客户？手机号和合同价格要不要交给模型？它只负责读数据，还是可以顺手修改 CRM？日报可以自动生成，那能不能自动发送？如果 CRM 和财务系统里的数字不一样，它听谁的？它说月底能完成 1200 万，这到底是目标、预测还是已经确认的收入？
前一半属于权限管理，后一半属于证据门禁。
 — 未授权读取目录
权限管理的核心确实是凭据，但不能只管一把 Key#
Agent 想进入企业系统，要先证明自己是谁。人有工号和账号，程序有服务账户，Agent 也应该有独立身份。直接把管理员的 API Key 填进配置文件，当然能跑，但系统只知道管理员做了一次操作，不知道背后是哪一个 Agent、代表谁、为了什么任务。
凭据解决 Agent 以什么身份进门，权限决定它进门以后能走到哪里。
更稳妥的做法，是让日报 Agent 拥有自己的服务身份。长期数据库密码放在企业的密钥系统里，不进入模型上下文，也不写进提示词。日报开始运行时，控制系统给它换取一个短期 Token；任务结束或者超过时间，Token 自动失效。
仅仅做到这一步还不够。身份是真的，不代表权限就应该很大。
这个短期凭据可以被限制为只读，只能读取经营日报需要的几张表，只能访问本公司这个租户，只能查看最近 30 天的数据。客户身份证号、手机号等字段在数据库或者工具层就应该被遮蔽，不能把完整数据先交给模型，再提醒它“不要泄露”。
这不是安全洁癖。如果日报 Agent 复用了管理员账户，一条错误指令就可能把客户手机号、合同价格带进不该出现的报告，甚至写回 CRM。事后日志里只剩下“管理员执行过操作”，很难追到具体是哪一个 Agent、代表谁、为什么越过了边界。
权限还要落到动作上。
日报 Agent 查询数据和生成草稿，可以自动完成；把内容发进管理群，需要单独授权；如果它发现某个客户长期未跟进，可以生成提醒，但不能直接修改销售负责人的任务；如果日报里涉及退款异常，它可以列出名单，不能顺手完成退款。
查询和退款如果共用同一份高权限凭据，模型看错币种、重复调用接口，或者把 1000 元识别成 10000 元，错误就会直接变成资金损失，后面还跟着财务对账和客户解释。
真正落到项目里，这些限制不能散在几段提示词和口头约定里。我更愿意把它写成一张权限卡，让开发、业务和安全人员看的是同一份东西：
agent: 经营日报 Agent
identity: 独立服务账户
read: 脱敏后的订单、工单、预算数据
write: 禁止修改 CRM 和订单
send: 仅生成草稿，发送前由负责人确认
limits: 最近 30 天、当前租户、内部管理群
credential: 短期 Token，任务结束后失效
这张卡真正管用的地方，在于把“大家应该都知道”的边界，变成系统可以执行、事后可以追查的规则。换成客服、合同审查或者投标 Agent，字段会变，身份、数据范围、动作范围和审批节点仍然要写清楚。
有些团队会把所有高风险动作都变成一个弹窗，让人不停点击“允许”。这看起来很安全，实际很容易把审批做废。Anthropic 公布过一项内部遥测：用户批准了大约 93% 的 Claude Code 权限提示。提示越多，人越容易不看内容就点同意。
真正有效的权限设计，不能把责任全部甩给弹窗。低风险操作在清晰的小范围内自动完成，高风险动作集中到少数值得认真确认的节点；数据权限、网络范围和工具能力尽量由模型外面的系统硬性限制。人负责判断，系统负责守住那些不能长期依赖注意力的边界。
这才是企业能逐步增加 Agent 自主权的方式。先把最坏结果关进一个足够小的范围，再根据实际运行记录扩大权限，而不是第一天就把所有系统交出去，然后期待模型一直听话。
权限只能拦住动作，拦不住一个错误结论进入日报#
日报 Agent 没有越权，数据也确实来自企业系统，报告就一定可靠吗？
不一定。
它可能把“本月目标 1200 万”写成“本月预计完成 1200 万”；可能把包含退款的订单金额当成收入；也可能看到 CRM 厂商写着“数据实时更新”，就默认每一条订单都已经同步。权限系统会认为整个过程完全合规，因为 Agent 只读了允许读取的字段，没有执行危险操作。
问题出在结论是怎么形成的。
我最初的做法，是把要求、计算、模拟、实测、供应商声明和认证做成六种标签。用来做内部记录没有问题，拿它们直接解释证据门禁就有些别扭：要求是一种主张，计算、模拟和实测是结果的形成方法，供应商声明与认证又属于来源和背书。它们根本不在同一条线上。
安全工程里有一套用了很多年的 Assurance Case。NIST 对它的定义很朴素：围绕一项主张，摆出支持它的证据和论证，同时写清假设，让整条判断可以被检查和追溯。
AI 写下结论只是起点。企业真正需要的是：这句话从哪来，中间怎么算，最后能拿去做什么。
拿“本月预计完成 1200 万”来说，这句话的身份是预测。它描述未来可能发生的结果，和已经完成的业绩、公司下达的销售目标都要分开。
接着才看它用了什么证据。可能是本月前 20 天的订单、已经发生的退款、剩余销售线索和工作日数量。仅仅把这些数据找出来还不够，还要知道数据是谁生成的、什么时候更新过、中间有没有被人改过。如果销售系统和财务系统的口径不同，这个冲突也得留下，不能让 Agent 挑一个更顺眼的数字。
证据和结论之间还有一段推导。比如先扣除退款，再根据前 20 天的日均成交额估算剩余工作日，同时假设退款率和线索量不会突然变化。这段推导决定了 1200 万是怎么算出来的，也暴露了它最容易出错的地方。删掉公式和假设，只留下最后的数字，预测很快就会被传成承诺。
最后才轮到门禁判断。带着完整数据和假设的 1200 万，可以放进销售团队的内部讨论；要进入正式经营日报，统计口径必须固定并且能够复算；准备写进客户承诺、合同或者对外材料，当前这些证据可能还不够，需要责任人确认，甚至补充正式记录。
如果要让系统自动处理，这条记录不需要写成论文，一张很小的证据卡就够了：
claim: 本月预计完成 1200 万
evidence: 前 20 天订单、退款记录、剩余线索
reasoning: 扣除退款后按剩余工作日外推
assumption: 退款率和线索量保持稳定
scope: 内部经营讨论
decision: 显示假设后放行
这样处理以后，原来的六个英文标签仍然可以留在系统后台：REQUIREMENT 记录要求，CALCULATED、SIMULATED 和 MEASURED 记录形成方法，SUPPLIER_DECLARED 与 CERTIFIED 记录来源和背书。它们不再假装是一套从低到高的证据等级，也不用让读者逐个背下来。
真正落到工程里，可以把这两张卡接成一条很短的流水线：
LLM 生成 claim_packet
→ Policy Engine 检查身份、数据范围和动作权限
→ Evidence Verifier 按 evidence_id 回查原始记录并复算
→ Gate 返回 allow / qualify / request_evidence / block
→ Delivery 发送结果，高风险动作等待人工批准
evidence_id 最好指向带时间、版本或校验值的原始记录，不要只把一段复制出来的文字塞进证据卡。发送或执行之后，还要回查邮件、订单、支付等外部系统的最终状态。日志里写着“工具调用成功”，只能证明接口返回过一次；真实系统有没有发生变化，才是任务是否完成的依据。
证据门禁不是让另一个 AI 再看一遍#
把主张、证据、推导和适用范围摆在一起，才轮到门禁判断。数据没有更新时间，先标记为可能过期；CRM 与财务系统冲突，暂停自动发送；预测没有假设，不允许进入结论区；供应商声明可以引用，但不能替客户完成安全判断。
证据不够时，也不一定把整段删除。可以把“已经实现”改成“当前测试中观察到”，把“必然完成”改成“按现有数据和假设测算”。
这里还要防一个看似高级的做法：让第二个 Agent 审查第一个 Agent。
AI 可以参加审查，但“另一个模型也同意”本身不是独立证据。两个模型可能读了同一份错误数据，也可能一起忽略统计口径。Anthropic 在 Agent 评测中专门区分了运行轨迹和最终结果：Agent 在回复里说“航班已经订好”，不代表数据库里真的存在一张预订记录。
更可靠的检查通常很朴素：重新执行查询，核对原始订单，检查公式，对比另一个业务系统，确认数据时间，抽样复查，或者交给真正承担责任的人批准。模型审查适合找遗漏，确定性规则和真实环境负责证明结果。
证据门禁还应该允许 Agent 说“目前无法确认”。OpenAI 对幻觉的研究指出，只奖励回答正确、不给放弃回答留位置，会鼓励模型在不确定时猜测。企业日报如果规定每个栏目必须填满，Agent 找不到数据也会努力补出一个看起来合理的数字。
空着并不可怕。把猜测写进经营决策，才可怕。
换成知识库和客服，这两道门照样存在#
经营日报只是一个容易看懂的入口。企业知识库里，同样的问题会换一种方式出现。
员工问“这个客户能不能查看我们的底价”，RAG 可能同时找到销售记录、旧版合同和一份过期的权限说明。权限管理先决定提问者能不能看到这些文件，证据门禁再判断回答引用的是哪一版规则，原文是否真的支持“可以查看”。RAG 能找到材料，不代表材料支持答案；附上一条链接，也不能自动证明那句话没有被模型曲解。
到了客服场景，政策允许“签收七天内无理由退款”，只是一条规则；订单的签收时间和商品状态，才是当前事实。Agent 需要把两者合在一起，才能判断这位客户是否符合条件。查询订单、生成回复和真正执行退款，也应该是三个不同的权限阶段。少了任何一步，系统都不该直接把钱退出去。
行业分析、投标材料和自动写作也是同一回事。内部销量和客户访谈能不能读取，先看权限；市场规模是公开数据、内部测量还是情景估算，要把来源和算法留下；一句话准备进入内部草稿、客户方案还是公开文章，再决定它需要多强的证据。
具体工具会变，先限制 Agent 能碰什么，再确认它的话凭什么成立，这两条线不会消失。
FDE 要把两道门带回研发后台#
FDE 要把客户现场那些藏在销售、财务、客服和管理层经验里的规则，翻译成身份、凭据、动作、审批、证据和发布门槛。现场验证过的权限模板、证据字段和门禁规则还要回到研发后台，下一个同类项目才能直接复用，而不是再做一遍定制开发。
 — 未授权读取目录
这也是我现在理解的企业 Harness。它不是某个产品名字，也不等于给模型多装几个工具。它把企业对权力和事实的要求，写进 Agent 每一次行动和每一份结果里。
模型决定任务有没有可能完成，Harness 决定企业敢不敢让它完成。
我是 Miles，一名从大厂转型 FDE 的 AI 算法工程师，做过算法优化部署，也做过企业内部沟通与培训。
关注我 @miles_mazy ，我会继续把 AI 从演示走到企业交付时真正会遇到的问题讲清楚。
一起成长，一起赚钱。