夏目 AI Delivery Engineer

当模型能自己行动，产品应该如何设计它周围的环境？

Agent 产品的关键不是写出更长的 Prompt，而是为模型提供可观察、可行动、可验证且受约束的环境。本文从一次真实对话失误出发，讨论 Skill、工具、Harness、CLI 与 LangGraph 的职责边界。

AgentHarnessSkillMCPLangGraph

当模型能自己行动，产品应该如何设计它周围的环境？

最近我在做一个达人营销项目交付 Agent，遇到了一段很小、但很有代表性的对话。

Agent 先问用户：

我们要继续刚才的华为 Mate 90 新品推广项目吗？

用户回答：

是的。

Agent 接着回复：

这是要新建项目，还是继续已有项目？请提供已有的 `customer_id` / `project_id`。

这显然不是一个好的回答。

用户已经确认“继续刚才的项目”，Agent 却再次追问是新建还是继续；系统本来具备查询客户和项目的工具，Agent 却把内部 ID 的查找责任推给了用户。

第一反应很容易是：修改 Prompt，加一句“不要向用户索要 `customer_id` 和 `project_id`”。

但继续讨论后，我发现问题并不只是一句提示词写得不好。它暴露的是一个更根本的产品设计问题：

如果模型已经能够自己规划和行动，我们应该怎样设计它周围的环境？

“缺少信息”不等于“询问用户”

传统表单和流程系统有一种很直接的设计方式：某个字段为空，就让用户填写。

但 Agent 不应该只是一个会说话的表单。

一个信息缺失时，至少要先判断它属于哪一类：

  1. 当前对话里已经出现的信息。
  2. 已有业务上下文中保存的信息。
  3. 可以通过只读工具查询的信息。
  4. 可以根据事实可靠推导的信息。
  5. 只有用户才能做出的业务判断。

Agent 应该按照这个顺序尝试解决问题。只有前四种来源都无法解决，或者结果存在需要业务人员判断的歧义时，才应该询问用户。

`customer_id` 和 `project_id` 属于系统内部状态。只要用户已经提供了客户名称、项目名称或清晰的上下文线索，Agent 就应该先查询。

但“这次要找什么样的达人”“目标市场是什么”“更重视曝光还是转化”属于客户的业务决策。工具不能替客户决定，这时才应该追问。

因此，更准确的规则不是：

缺少必要信息时，向用户收集。

而是：

缺少必要信息时，先判断信息来源。
能够从上下文或工具获得的信息，由 Agent 自己解决；
只有无法自行获得的业务判断，才向用户收集。

这个差异看起来很小，却决定了产品究竟是“有自主能力的 Agent”，还是“披着聊天外壳的流程表单”。

工具是手和脚，模型才是大脑

我们很容易把 Skill 写成一份详细操作手册：第一步做什么，第二步查什么，第三步问什么，第四步输出什么。

这种方法短期内很稳定，因为模型只需要照着执行。但当真实用户不按预设流程表达时，问题就会出现。

用户可能先说项目，也可能先说产品；可能在一句话里同时给出客户、市场和达人要求；也可能只说“继续刚才那个项目”。如果 Skill 把每一步都规定死，模型就会为了遵守流程而忽略上下文。

更合适的关系是：

工具是 Agent 的手和脚，模型是大脑，Skill 是能力地图、业务知识和安全边界。

工具告诉模型它能做什么，Skill 帮助模型理解业务，Harness 让模型能够持续观察、行动和获得反馈。具体调用哪些工具、按什么顺序调用，应该由模型根据用户目标自主决定。

这并不意味着 Skill 没有价值，也不意味着所有规则都应该删除。

Skill 仍然适合描述：

  • Agent 负责解决什么业务问题。
  • 有哪些业务对象和关键概念。
  • 什么结果算完成。
  • 哪些事实不能推断或编造。
  • 哪些操作存在成本或风险。
  • 哪些领域知识不是通用模型天然具备的。

但 Skill 不应该代替模型做完整的行动规划，更不应该把每种对话写成固定剧本。

真正需要设计的是 Agent Harness

当我们开始讨论“模型周围的环境”，其实已经进入了 Agent Harness 的范畴。

Harness 不是某一个 Prompt，也不是某一个工具。它是包围模型的一整套运行环境，负责把一次模型回答变成一个能够持续工作的 Agent。

一个完整的 Harness 通常包含：

能力作用
上下文组装把用户消息、当前客户、当前项目和相关规则提供给模型
工具发现告诉模型当前可以读取或改变哪些业务对象
Agent Loop接收模型的工具调用，执行后把结果重新交给模型
会话与状态保存 thread、业务上下文和中间结果
权限与确认在写入、付费或高风险操作前暂停并确认
Sandbox从技术上限制模型能访问的文件、网络和系统
错误反馈返回可重试、不可重试、部分成功或需要人工判断的结果
Trace 与评测记录 Agent 为什么调用工具，以及最终结果是否满足目标

它形成的是一个循环：

用户目标
  -> 模型观察上下文与能力
  -> 模型制定当前计划
  -> 调用工具
  -> 环境校验并执行
  -> 返回真实结果
  -> 模型继续规划、完成任务或向用户暴露阻断问题

模型负责判断“下一步做什么”，Harness 负责保证“它能看到真实状态、执行真实动作，并受到可靠约束”。

Codex 为什么像一个通用 Agent

Codex 是一个很值得参考的例子。

它的通用性并不是来自一个覆盖所有软件开发场景的巨大 Skill，而是来自一个完整 Harness：

  • 模型可以读取工作区和代码上下文。
  • 可以使用终端、文件编辑、Git、Web 和 MCP 工具。
  • 工具执行结果会重新进入对话，模型可以继续推理。
  • `AGENTS.md` 提供仓库级持久指导。
  • Skills 按任务相关性渐进加载。
  • MCP 和 Plugins 提供外部数据与动作。
  • Sandbox 决定技术上允许做什么。
  • Approval policy 决定什么时候必须询问用户。
  • 测试、lint、diff 和命令结果提供可验证反馈。

可以把 Codex 简化成下面这个公式：

Codex = 通用模型 + Agent Harness + 可操作环境 + 可插拔领域能力

这也说明了一个重要问题：Skill 只是 Harness 中的一个扩展层，不应该承担全部规划、状态管理、权限控制和工具编排。

如果我们把所有业务逻辑都塞进一个 Skill，本质上是在用提示词模拟 Harness。提示词会越来越长，模型会越来越机械，安全规则也只能依赖模型“记得遵守”。

工具应该面向用户目标，而不是映射内部 API

能力型 Agent 对工具的要求，比普通后台 API 更高。

如果系统只暴露：

GET /projects
GET /projects/:id
POST /projects

模型虽然理论上可以组合它们，但仍然需要理解大量内部实现细节。

更适合 Agent 的工具应该围绕业务意图设计，例如：

resolve_project
get_current_requirements
preview_customer_update
search_creators
record_creator_review
confirm_shortlist

以 `resolve_project` 为例，它可以接收用户提供的名称、品牌或对话线索，返回：

  • 唯一匹配：直接恢复项目上下文。
  • 多个匹配：返回足够业务化的信息，让用户选择。
  • 没有匹配：明确告诉模型没有已有项目。
  • 查询失败：返回是否可重试以及失败类型。

这样模型不需要让用户提供内部 ID，也不需要自己拼接底层数据库查询。

工具还应该明确声明：

  • 输入和输出结构。
  • 是否只读。
  • 是否会修改外部状态。
  • 是否消耗费用或额度。
  • 需要什么权限。
  • 失败后能否重试。
  • 是否需要人工确认。

不可妥协的规则应该由工具和服务端执行，而不是只写在 Skill 里。

例如：

  • 写操作默认只生成预览。
  • 重复请求需要幂等保护。
  • 付费查询必须携带确认状态。
  • 非法项目状态转换由 API 拒绝。
  • 联系方式导出能力如果不允许，就根本不向模型提供。

正确的产品设计不是反复提醒模型“不要做错”，而是让正确动作容易执行，让错误动作在系统层不可执行。

开发 Agent 必须使用 LangGraph 吗？

不必须。

LangGraph 是一个低层的 Agent 编排运行时。它擅长解决：

  • 长时间运行任务的持久化。
  • 失败后的检查点恢复。
  • 固定节点和分支的编排。
  • Human-in-the-loop 的暂停与继续。
  • 多 Agent 的确定性交接。
  • Agent 步骤和传统工作流步骤的混合。

这些能力很重要，但它们解决的是复杂编排问题，不会自动提升模型的业务判断能力。

如果产品当前只是：

  • 理解用户业务目标。
  • 查询客户和项目。
  • 收集无法自行获得的业务条件。
  • 调用达人搜索工具。
  • 展示结果并等待确认。

那么一个通用模型、轻量 Harness、结构化工具、薄 Skill 和可靠 API 已经足够。

过早引入 LangGraph，反而可能把还没有稳定的业务过程固化成节点和边。团队会花很多时间维护流程图，却没有改善工具能力、上下文质量和评测体系。

当未来出现下面这些场景时，再考虑引入 LangGraph 或其他工作流引擎会更合理：

  • 一个任务要跨几小时或几天暂停恢复。
  • 多个步骤必须在指定节点等待人工审批。
  • 失败后必须从精确检查点继续。
  • 存在复杂并行分支、补偿和回滚。
  • 多个专业 Agent 有稳定的交接拓扑。

例如，“帮我找适合华为新品推广的达人”通常不需要 LangGraph；但“确认名单后分批建联、等待回复、超时重试、人工介入并持续回写状态”可能需要持久化工作流。

一个更适合业务 Agent 的架构

以达人营销项目交付为例，我目前更倾向于下面的结构：

飞书 / ChatGPT / Codex
        |
        v
轻量 Agent Harness
- 用户与租户身份
- 会话和上下文
- 模型工具调用循环
- 成本与写操作确认
- 日志、Trace 和评测
        |
        v
业务能力工具 / MCP
- resolve_customer
- resolve_project
- get_current_requirements
- save_current_requirements
- search_creators
- add_candidates
- record_creator_review
- confirm_shortlist
        |
        v
Yalaya API + NoxInfluencer
        |
        v
业务数据库与外部数据

在这个架构里：

  • 模型负责理解客户目标和决定行动组合。
  • Harness 负责上下文、循环、确认和运行状态。
  • MCP 或结构化工具负责暴露业务能力。
  • API 负责数据真实性、权限、幂等和状态约束。
  • Skill 负责领域知识、结果标准和关键边界。
  • Eval 负责验证 Agent 在真实对话中有没有退化。

CLI 仍然有价值，尤其适合内部调试、管理员操作和 Agent 的早期工具适配。但面向生产环境时，最好在 CLI 或底层 API 之上提供稳定的结构化工具，而不是让模型自由拼接 Shell 命令。

从“设计流程”转向“设计环境”

过去设计 AI 产品时，我们习惯先画流程：用户点哪里，系统展示什么，下一步进入哪个页面。

当模型能够自主规划后，设计重点会发生变化。

我们不再需要规定每一次行动，而需要回答：

  1. 模型现在能观察到哪些真实状态？
  2. 它具备哪些清晰、可组合的业务能力？
  3. 哪些信息可以自行获得，哪些必须由用户决定？
  4. 哪些边界由系统强制执行？
  5. 每次行动后，它能否得到足够明确的反馈？
  6. 失败时能否重试、恢复或正确升级给用户？
  7. 我们如何通过真实场景评测它是否做对了？

这是一种从“设计用户流程”到“设计 Agent 环境”的转变。

最终，我对 Agent 产品的理解可以总结成一句话：

不要试图用更长的 Prompt 遥控模型；应该为模型提供一个能力清晰、状态真实、反馈完整、边界可靠的环境，让它自己完成规划。

AI 是大脑，工具是手和脚，Harness 是神经系统和活动空间，Skill 是领域知识与能力地图。

当这些部分的职责被正确划分后，Agent 才真正有机会从“会聊天的流程机器人”变成“能够独立解决问题的业务协作者”。

参考资料