---
title: "AI 已经够用了，难的是选对 Harness"
author: "Shawn Jiang"
lang: zh
date: 2026-08-25
canonical: https://tplog.dev/zh/essay/ai-harness-business-decision/
translations:
  en: https://tplog.dev/en/essay/ai-harness-business-decision/
  ja: https://tplog.dev/ja/essay/ai-harness-business-decision/
---

# AI 已经够用了，难的是选对 Harness

前阵子，我在拆一个 HubSpot 查询需求。目标只有一句话：员工输入自然语言，就能查到自己权限范围内的数据。

听上去只要把模型和 API 接起来就行：模型能理解问题，HubSpot 也有 API。可自然语言问题最终要变成一次真实请求，中间还需要一套系统负责调用工具、传递参数和整理结果。

我先沿着 Dify 这条路线往下拆。它可以连接模型、流程和外部工具。查询路径固定时，用[工作流应用（Workflow app）](https://docs.dify.ai/en/cloud/use-dify/build/workflow-chatflow)提前编排，让 LLM 理解问题，再由 HubSpot 工具节点查询 CRM；问题较开放时，在工作流中加入[经典 Agent 节点（Classic Agent node）](https://docs.dify.ai/en/cloud/use-dify/nodes/agent)，让模型临场选择工具。

<figure class="figure">
  <img src="/images/essay/ai-harness-business-decision/classic-agent-node.png" alt="Dify 工作流画布中的经典 Agent 节点配置面板，包含 Agent 策略等参数" width="900" height="1140" loading="lazy" decoding="async" />
  <figcaption class="figure-caption">经典 Agent 节点位于工作流应用内部。图片截取自 <a href="https://docs.dify.ai/en/cloud/use-dify/nodes/agent">Dify Cloud 官方文档</a></figcaption>
</figure>

两种方式都只能调用平台预先配置的工具，没有可以安装软件、保存文件和运行命令的环境。

## Dify 里有两套 Agent

Dify 还保留着[旧版 Agent 应用（Legacy Agent app）](https://docs.dify.ai/en/cloud/use-dify/build/agent)。它是独立的应用类型，经典 Agent 节点则位于工作流内部；但两者都是让模型调用预配置工具，都没有通用 Shell，不能直接运行 HubSpot CLI。

<figure class="figure">
  <img src="/images/essay/ai-harness-business-decision/legacy-agent-app.png" alt="Dify 应用类型选择器中的 Agent 卡片，说明 Agent 是独立的应用类型" width="431" height="218" loading="lazy" decoding="async" />
  <figcaption class="figure-caption">旧版 Agent 是一个独立应用类型，但仍通过模型调用预配置工具。图片截取自 <a href="https://docs.dify.ai/en/learn/key-concepts">Dify 官方文档</a></figcaption>
</figure>

Dify 1.16 又引入了 [Dify Agent（Beta）](https://docs.dify.ai/en/self-host/use-dify/build/new-agent/overview)，官方文档也称 New Agent。它是工作区中可以管理和复用的 Agent 实体，拥有自己的 Agent Runtime 和 Linux Sandbox，可以运行命令、安装程序、读写文件。

<figure class="figure">
  <img src="/images/essay/ai-harness-business-decision/dify-agent-beta.png" alt="Dify Agent Beta 的工作区配置页面，展示模型、Prompt、Skills、Files 和 Tools 等能力" width="1524" height="1210" loading="lazy" decoding="async" />
  <figcaption class="figure-caption">新版 Dify Agent 是工作区中单独管理的实体，不是旧版 Agent 应用或工作流节点。图片截取自 <a href="https://github.com/langgenius/dify/releases/tag/1.16.0">Dify 1.16.0 官方发布说明</a></figcaption>
</figure>

Dify Agent 可以独立发布，也可以通过工作流中的[新 Agent 节点（New Agent node）](https://docs.dify.ai/en/self-host/use-dify/nodes/agent#new-agent)调用。节点只是入口，真正带着能力和 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 是否完整继承员工的记录可见性，以及隔离方案能否承担凭证风险。在这两点明确之前，扩大试做范围没有意义。

## 资料来源

- [Dify：Workflow 与 Chatflow](https://docs.dify.ai/en/cloud/use-dify/build/workflow-chatflow)
- [Dify：旧版 Agent 应用](https://docs.dify.ai/en/cloud/use-dify/build/agent)
- [Dify：Dify Agent（Beta）](https://docs.dify.ai/en/self-host/use-dify/build/new-agent/overview)
- [Dify：Dify Agent 的 Linux Sandbox](https://docs.dify.ai/en/self-host/use-dify/build/new-agent/build)
- [Dify：Agent 节点](https://docs.dify.ai/en/self-host/use-dify/nodes/agent)
- [Dify 1.16.0：Dify Agent 发布说明](https://github.com/langgenius/dify/releases/tag/1.16.0)
- [HubSpot：使用 Personal Access Key 验证 CLI](https://developers.hubspot.com/docs/developer-tooling/local-development/hubspot-cli/personal-access-key)
- [HubSpot：Private Apps](https://developers.hubspot.com/docs/apps/legacy-apps/private-apps/overview)