AI 已经够用了，难的是选对 Harness
前阵子，我在拆一个 HubSpot 查询需求。目标只有一句话：员工输入自然语言，就能查到自己权限范围内的数据。
听上去只要把模型和 API 接起来就行：模型能理解问题，HubSpot 也有 API。可自然语言问题最终要变成一次真实请求，中间还需要一套系统负责调用工具、传递参数和整理结果。
我先沿着 Dify 这条路线往下拆。它可以连接模型、流程和外部工具。查询路径固定时，用工作流应用（Workflow app）提前编排，让 LLM 理解问题，再由 HubSpot 工具节点查询 CRM；问题较开放时，在工作流中加入经典 Agent 节点（Classic Agent node），让模型临场选择工具。
两种方式都只能调用平台预先配置的工具，没有可以安装软件、保存文件和运行命令的环境。
Dify 里有两套 Agent
Dify 还保留着旧版 Agent 应用（Legacy Agent app）。它是独立的应用类型，经典 Agent 节点则位于工作流内部；但两者都是让模型调用预配置工具，都没有通用 Shell，不能直接运行 HubSpot CLI。
Dify 1.16 又引入了 Dify Agent（Beta），官方文档也称 New Agent。它是工作区中可以管理和复用的 Agent 实体，拥有自己的 Agent Runtime 和 Linux Sandbox，可以运行命令、安装程序、读写文件。
Dify Agent 可以独立发布，也可以通过工作流中的新 Agent 节点（New Agent node）调用。节点只是入口，真正带着能力和 Sandbox 工作的是 Dify Agent。
截至 2026 年 8 月 25 日，带 Linux Sandbox 的 Dify Agent 尚未作为公开支持的 Dify Cloud SaaS 功能开放，只在 Self-host 文档中出现。因此，如果方案依赖 HubSpot CLI，那么在 OSS 和 Cloud 之间，能明确支持它的是自行部署 Community Edition，而不是 Dify Cloud。
到这里，Harness 才真正出现：它不是某个应用类型，而是模型、工具、身份、权限、凭证和 Runtime 的组合。模型决定 AI 会不会做，Harness 决定它能不能在真实业务里做。
Runtime 会改变身份和权限模型
一种做法是使用 Private App Access Token。它代表应用，不代表正在提问的员工。所有查询默认走同一套应用权限；要限制每位员工能看到什么，还要另外识别员工并过滤数据。
另一种做法是让每位员工使用自己的 HubSpot Personal Access Key。这个 Key 用于 HubSpot CLI 和本地开发工具，可选择的 Scopes 受该员工的 HubSpot 用户权限限制。
个人 Key 方案要求隔离的执行环境：Sandbox 要能安装 HubSpot CLI、保存该员工的 ~/.hscli/config 并执行命令。只有这样，员工身份、CLI 和凭证才能绑定在一起。
Dify Agent 的 Linux Sandbox 让这条路线成为可能，但它不等于每位员工天然拥有安全隔离的账号环境。Community Edition 的 Agent Runtime 不是隔离互不信任用户的 hardened security boundary，Dify 也不会按终端员工自动切换 HubSpot 凭证。团队仍要设计凭证分发和环境隔离。
Personal Access Key 的官方定位是 CLI 和本地开发。把它用于企业内部助手，还要承担密钥保存、轮换、离职撤销和审计等成本；它是否完整复刻 HubSpot 界面的记录可见性，也需要另外验证。
试做之前的判断值多少钱
如果团队不了解这些差异，很容易做到一半才发现方案没有 CLI Runtime；转向 Community Edition 后，又引入新的运维和安全成本。凭证代表应用还是员工，也会把系统带向完全不同的权限模型。
这些问题可以靠试做发现，但试做需要工程师、环境和时间。有些方案即使能做出来，也不值得投入这些成本。
这个案例也让我更确定 AIBP 和 FDE 的价值。内部的 AIBP（AI Business Partner）负责把需求、权限、成本和业务指标转化为 AI 方案；厂商侧的 FDE（Forward Deployed Engineer）负责验证产品边界并交付方案。
他们先把目标拆成约束：查询是否固定，是否需要动态选工具，身份属于个人还是应用，是否必须使用 CLI，权限需要精确到什么程度，公司愿意承担多少部署和运维成本。然后排除不成立的路线，只把剩余的不确定性交给最小规模的技术验证。
AIBP 更靠近业务决策，FDE 更靠近技术交付。两者的价值来源相同：缩短从业务问题到正确系统之间的距离。
先判断，再做 Demo
回到这个 HubSpot 需求，我的判断是：接受应用级凭证、流程稳定，就用工作流应用；意图开放，就加入经典 Agent 节点并限制可用工具；必须使用员工自己的 CLI 身份，才评估带 Linux Sandbox 的 Dify Agent，并承担密钥、隔离和运维成本。
Demo 只需继续验证两件事：Personal Access Key 是否完整继承员工的记录可见性，以及隔离方案能否承担凭证风险。在这两点明确之前，扩大试做范围没有意义。