把岗位拆成Agent任务：用代码定义范围、限制与升级

当团队说“我们想要一个AI员工”时，第一件事不是选模型，而是把一个岗位拆成可指定、可限制、可检查的任务。本文用一个销售运营分析师的示例角色，展示如何用代码写下这份任务规格。

为什么先拆任务，而不是先选模型

原文作者Tej Pandya开篇就点明：从“AI员工”的模糊需求到可落地的系统，中间隔着一层任务规格。模型选型是最后一步，而不是第一步。

这个观点与Anthropic的智能体设计指南相互印证。该指南将工作流（workflow，固定代码路径）与智能体（agent，由模型决定步骤）明确区分，并指出智能体带来更高的成本和复合错误风险，因此建议先在沙箱中带护栏测试。原文据此给出了一条保守原则：每个任务都从工作流开始，只有当步骤确实无法固定时，才迁移到agent模式。

这背后的逻辑很直接：工作流的执行路径可预测、可审计，而agent的每一步选择都可能引入偏差。把任务拆得足够细，才能让“交给AI”这件事变得可控。

任务规格的核心字段

原文用Python的dataclass定义了一个TaskSpec，包含几个关键字段：任务名、输入、允许的工具列表、输出形式、人类负责人（owner），以及升级条件（escalate_when）。还有一个容易被忽略但至关重要的mode字段，用来标记该任务是工作流还是智能体。

以示例中的clean_lead_list任务为例：输入是CRM线索，允许的工具只有crm.read和crm.update_field，输出是带原因的修改列表，负责人是运营主管，遇到“合并两条记录”的情况必须升级给人类。

另一个任务draft_followup则更保守：只允许读取CRM和起草邮件，输出明确标注“仅草稿，永不发送”，遇到提及价格或退款的情况立即升级。

工作流与智能体的本质区别在于控制权的归属。工作流模式下，每一步操作由开发者预先编排的代码路径决定，模型只在固定节点上执行特定子任务（如分类、抽取、生成文本），整体行为完全可预测、可复现。智能体模式则把“下一步做什么”的决策权交给模型，模型根据当前上下文自行选择工具、拆解子目标、循环执行，直到它判断任务完成。这种灵活性带来两个代价：一是每次模型决策都可能偏离预期，错误会在多步之间复合放大；二是token消耗和延迟随步骤数线性甚至指数增长。因此工程上更稳妥的做法是“能编排就不放权”，先把流程中确定的部分固化为工作流，只把真正无法预先枚举分支的环节交给智能体，并且必须配上工具白名单、步数上限和人工升级出口。

把限制写在代码里，而不是提示词里

原文最有力的一个观点是：允许的工具清单和止损词应该存在于代码中，而不是提示词中。“提示词可以被说服，代码里的检查不能。”

run函数的逻辑很简洁：在每一步执行前，先检查该步骤要调用的工具是否在允许列表中；再检查步骤文本是否命中了升级关键词；两者任一触发，就立即升级给人类负责人。只有通过检查的步骤才会真正调用工具，并把输入输出写入审计日志。

这种设计解决了什么问题

大语言模型对提示词注入和越权请求缺乏天然免疫力。把边界放在模型之外，意味着即使模型“想”调用一个不该调用的工具，代码层也会拦截。这种防御性设计不需要信任模型的行为，只需要信任代码的执行。

与之配套的是审计日志：每一次工具调用及其结果都被记录。这为后续的抽样审查提供了数据基础，也让“AI做了什么”不再是一个黑箱。

提示词注入（prompt injection） 是指攻击者把恶意指令藏进模型会读取的内容里——比如CRM备注、邮件正文或网页文本——诱导模型忽略原有指令、执行攻击者想要的操作。由于大语言模型无法可靠区分“系统指令”和“用户数据”，单靠提示词里的“不要做X”很容易被一段精心构造的文本绕过。防御的关键是把安全边界下沉到模型之外：在工具调用层做白名单校验，在执行层做参数检查和权限控制，在输出层做敏感操作拦截。这样即便模型被说服，实际动作仍会被代码拦下。本文的run函数正是这一思路的体现——每一步执行前先校验工具是否在允许列表、文本是否命中升级关键词，模型输出只是“提议”，最终是否执行由确定性代码裁决。

审计日志（audit log） 在此类系统中不仅是记录，更是信任建立的基础设施。一条合格的审计记录至少应包含：时间戳、任务标识、步骤序号、拟调用的工具名及参数、模型的原始输出、代码层的放行或拦截决定、实际执行结果。有了这些字段，负责人才能做两类审查：其一是事后抽样，检查模型是否在边界内完成了正确的事；其二是回溯归因，当出现错误时定位是模型判断失误、工具接口问题还是规则设计漏洞。审计日志还支撑“渐进式放权”——只有当某任务在足够多的样本中表现稳定、未触发意外升级时，才考虑放宽工具范围或减少人工复核频率。没有日志，扩大自动化范围就只能靠感觉，而这正是多数AI项目失控的起点。

最小权限原则（principle of least privilege） 源自信息安全领域，指任何执行主体只应获得完成其当前任务所必需的最小权限。在智能体设计中，这一原则体现为工具白名单：clean_lead_list只能读CRM和更新字段，draft_followup只能读CRM和起草邮件且永不发送。权限收窄的直接收益是缩小爆炸半径——即使模型被注入攻击或产生幻觉，它能造成的破坏也被限制在几个低风险操作内。与之配套的是“人在回路”（human-in-the-loop）升级机制：当任务触及高影响操作（合并记录、提及价格退款）时，系统不自行处理，而是把上下文打包交给人类决策。最小权限与人在回路结合，才能让自动化在可控范围内逐步扩展，而不是一次性把高风险权限交给一个行为不完全可预测的模型。

每个任务必须有人负责

原文将owner设为必填字段，规则简单粗暴：没有负责人的任务不允许上线。负责人每周从审计日志中抽样审查，并有权随时关闭该任务。

这一设计与微软Work Trend Index中的观察相呼应（原文引用的是该报告的2025版）：该报告将智能体描述为“数字同事”，在人类指导下承担任务，并把管理这些智能体的人称为“agent boss”。原文认为，这个“agent boss”角色恰好对应任务规格中的owner字段。

说个细节，原文作者明确划定了边界：这里的智能体只是一组带限制的任务集合，在任何法律意义上都不是员工，这份规格也不能替代一个岗位。这种克制在当下“AI员工”叙事泛滥的语境中显得难得。

小步推进的三条原则

原文给出了保持声明保守的三条实践原则：在负责人信任某个任务之前，只做草稿不执行发送；记录每一次工具调用的输入和输出；止损规则应来自真实事故，而非主观猜测。

第三条尤其关键。很多团队在设计护栏时凭想象列出风险点，但真正的风险往往出现在意料之外。从真实事故中提炼规则，意味着这套限制会随着运行逐步收紧，而不是一开始就完美。

从任务规格到审查闭环

原文的收尾指向一个持续循环：从审计日志抽样，收紧规则，然后再扩大任务范围。这是一个渐进式放权的思路，而不是一次性把整个岗位交给AI。

这套方法的可迁移性较强。无论团队要自动化的是销售运营、客服分诊还是数据清洗，核心步骤是一致的：先列出任务而非岗位，为每个任务定义允许的工具和升级条件，把限制实现在代码层，指定人类负责人，然后通过日志审查逐步扩大信任边界。

真正的难点不在于写这几个dataclass，而在于组织是否愿意接受“AI只做被明确限定的那部分”。这需要把模糊的岗位期待翻译成精确的工程规格，而这恰恰是当前多数“AI员工”项目跳过的第一步。