给 AI 定岗：从 DeepSeek Harness 的 Agent 预设看企业 Agent 岗位设计

上个月帮一个业务团队看 Agent 试点，对方第一句话是「我们想上 DeepSeek 的模型，听说便宜」。我问他：这个 Agent 上线以后是谁？是给销售报价的助理，还是替商务查舱位的工具，还是什么都干一点的通用助手？他愣了一下，说还没想过。

这个愣住，比模型选型错误更致命。因为模型选错了可以换，岗位没定义清楚，Agent 从第一天起就不知道自己是谁。

1. 一个预设拆开了四件事

DeepSeek Harness 是 DeepSeek 在 2026 年 8 月发布的首款 Agent 产品。它的核心概念叫「Agent 预设」（preset）——一个预设决定了一个会话里的 Agent 能看到哪些工具、提示词、Skill 和子 Agent。这也是我见过对一个 Agent 最干净的拆法：

• 模型 = 大脑：决定基础的推理和理解能力。
• Skill = 操作手册：告诉模型遇到某类任务时，具体怎么做。
• Tool / 插件 = 软件和权限：决定模型能否搜索、改文件、运行命令、收发邮件。
• Agent 预设 = 岗位 + 工作环境：身份、长期规则、可用工具、工作方式，都由预设决定。

翻译成企业语言，就是一句话：Agent 预设就是岗位说明书，工具是办公权限，Skill 是操作手册，模型是脑子。 你招人不会先问「买哪台电脑」，你会先写清楚这个岗位要干什么、边界在哪、需要哪些权限。企业落地 Agent 的顺序，应该和招人一样。

2. 企业最常见的顺序，是反的

我现场看到的常见顺序是这样的：先比模型（哪个聪明、哪个便宜）→ 再搭框架 → 最后才问「这个 Agent 到底负责哪段工作」。结果通常是 Demo 很漂亮，进了真实业务就散架——因为它没有身份，没有边界，也没有验收对象。

这不是模型的问题。同一个模型，在不同的工具组织、上下文管理和执行策略下，产出可以差很多。拿同一个 DeepSeek-V4-Flash 放到三个不同的 Agent 执行环境里跑同一个任务，结果差异肉眼可见。模型是同样的，变的是执行层的组织方式。

所以「先选模型」这个顺序本身，就把问题问小了。真正该先问的是：这个 Agent 的岗位是什么？它的长期规则是什么？它被允许碰什么、不碰什么？

3. 岗位说明书四件套

我给客户做 Agent 设计时，会先写一页「Agent 岗位说明书」，四件事：

第一件：身份。 它是谁？「物流询价助理」和「通用客服助手」是两份完全不同的工作。身份决定它接收什么任务、以谁的口吻输出、对什么结果负责。

第二件：长期规则。 哪些事必须做、哪些事绝对不做、哪些规则永远不能破。比如询价 Agent 的长期规则可能是：报价前必须确认起运港和目的港；没有船期数据时明确说不知道，不许编。规则写进预设里，等于写进岗位职责，而不是每次对话临时叮嘱。

第三件：工具与权限。 它能碰系统吗？能写回数据库吗？能发邮件吗？对应 DSH 里的 Tool/插件层。权限的边界，决定了 Agent 出错的代价上限。权限给得太满，公司不敢让它碰正式工作；给得太少，它什么都干不成。

第四件：工作方式。 它是单兵作战，还是需要调用子 Agent、走多步流程、定期复盘？它怎么组织上下文、怎么处理长任务？这一层决定它能不能真的跑完一段端到端的工作，而不只是答一道题。

写完这四件事，再选模型、配 Skill、开权限。模型只解决「聪明程度」，岗位说明书解决「干什么、边界在哪、怎么验收」。

4. 没有岗位说明书的 Agent，会怎样

说一个反复出现的现场：企业给 Agent 开了很大的权限，「它能查所有表格、能读所有聊天记录、能回客户」。听起来很强大，但真正上线时，业务负责人不敢用——因为没人说得清它什么时候会做什么，出了事找谁。

这正是「什么都干」的代价：没有边界的 Agent，等于没有 owner 的流程。我写过一篇《企业推进 AI 时，先找到流程 owner》，讲流程没人拍板会卡死；Agent 没有岗位说明书是同一件事的另一面——流程有 owner，但执行者不知道自己的职责边界，照样没法验收。

反过来，一旦岗位说明书写清楚，很多问题会自动消失：验收指标有了（按岗位结果验收，而不是按「AI 跑没跑」验收），权限审批有了依据（岗位需要什么权限，就给什么权限），异常接管也清楚了（超出岗位边界的任务，交给对应的人类 owner）。

5. 适用条件与未证明的部分

这个框架来自 DeepSeek Harness 的产品设计，以及我在真实业务里反复撞见的失败模式。它适合的，是已经决定要做 Agent、但还没想清楚「它到底是谁」的团队。

我不打算吹「写一页说明书就能成功」——它只是必要条件，不是充分条件。以下几个问题我还没看到完整答案，写出来免得误导：

• 岗位说明书写好了，但真实业务里的例外规则永远比写下来的多。规则维护谁来做、多久做一次，我目前靠流程 owner 兜底，还没有规模化的答案。
• DSH 的预设体系本身还在内测阶段，功能可能与正式版略有出入。它证明「预设」是一种可行设计，不证明所有 Agent 产品都应该这么做。
• 「Agent 定岗」会不会变成新的人事僵化——岗位写死了，Agent 反而失去灵活性？我倾向于先写死再放开，但这个假设还没有足够样本验证。

6. 一句可迁移的判断

把企业 Agent 落地当成招人，而不是选电脑。先写岗位说明书：身份、长期规则、工具权限、工作方式；再选模型、配 Skill、开权限。 模型是下限，岗位设计决定上限。

DeepSeek Harness 真正值得抄的，不是某个功能，而是这个顺序：它把「岗位」从「模型」里独立了出来。企业也一样——先回答「这个 AI 是谁、干什么、边界在哪」，再回答「用哪个模型」。前者想不清楚，后者选什么都白搭。

继续读：企业推进 AI 时，先找到流程 owner；Agent 怎样从任务走向一段正式工作；SOP 是 Agent 的边界。专题路径见组织与服务增长。