目标而非指令：如何写出AI智能体能真正接管的工作

在Google的Gemini at Work活动上，这家公司宣布其助手正在进化为一个智能体（agent）——能够规划工作、调用工具、代表你连接各类业务系统。大多数报道会聚焦于功能清单，但Google Cloud CEO Thomas Kurian的一句话比所有功能点都更值得关注：新的智能体可以被赋予**"目标，而不仅仅是指令"（objectives, not just instructions）**。

这短短几个词，恰好概括了小企业主下一步真正需要掌握的能力。不是写提示词（prompt-writing），而是委派（delegation）。而委派有一套规则，大多数人都是用笨办法摸索出来的——一套原本适用于员工的规则，如今也适用于软件。

指令与目标的本质区别

指令，是你负责思考、智能体负责打字：

"给周二询问报价的那位承包商写一封跟进邮件。"

目标，是你定义结果、智能体负责规划工作：

"每一份两周未回复的报价，必须在周五前得到明确的'接受'或'拒绝'。草稿排队等我审批。任何两次失联的客户，标记出来需要打电话。"

第二种表述才是杠杆所在。但这里有个陷阱：大多数人交给智能体的目标根本无法完成，因为目标缺失了三个智能体无法自行推断的要素。智能体会规划——但它不会读心。

每个目标都必须包含的三要素

1. 完成的定义（Definition of Done）。 "改善我们的跟进"是一个愿望。"每份过期报价周五前得到答复"才是目标——存在一个明确的时刻，让你能核验它是否真的发生了。如果你从外部都无法判断工作是否完成，智能体同样无法判断。先用一句话写下完成状态，并带上一个数字或日期。

2. 边界（Boundaries）。 智能体可以碰什么，绝不能碰什么。实用的版本很短：它可以读取报价日志、邮件历史和日历；可以起草对外消息；但未经审批不得发送任何内容，不得触碰任何涉及金钱的事务，不得主动联系任何陌生人。两份清单，五分钟写完，这就是"助手"与"事故"之间的分界线。

3. 升级规则（Escalation Rule）。 何时停下来询问你。有效的写法是："如果你不确定某件事是否符合边界，或客户的回复带有愤怒、法律相关或令人困惑的内容——停下来，交给我处理。"智能体最容易在你规则的"缝隙"中出错。给它一个明确的落脚点来处理这些缝隙。

如果你的目标包含这三要素，智能体就能据此规划。缺少任何一项，智能体都会用某种东西填补空白——而你不会喜欢它填进去的内容。

永远不要让第一版计划未经审查就运行

Google的公告把运行机制讲得很清楚：你给智能体分配工作、安排任务，或让它响应事件，然后它自己规划工作——创建一组子智能体（sub-agents），每个都有独立身份，并行执行多步骤任务。无论你最终用哪款工具，都把这当作范式：当智能体能够自主规划时，你的工作就不再是写步骤，而是读计划。

让"目标模式"安全运行的规则是：任何目标的第一次运行，都是提案，而非指令。 在智能体执行之前，先读它的计划。它会碰什么、按什么顺序？它会发送什么、发给谁？它自己发明了哪些你没预料到的子任务？

大多数第一版计划的错误都很乏味——它会优先处理错误的客户，或者用你们镇上没人会用的语气起草邮件。抓出这些问题只需五分钟。放任它运行，代价则是一周的善后，外加一个收到奇怪邮件的客户。当第一版计划通过审查后，后续运行只需抽查：每周一次，花二十分钟读一读实际发出去的内容。

子智能体（sub-agents）架构值得多说一句。在多智能体系统中，一个"编排者"（orchestrator）智能体负责理解目标、分解任务，再将子任务分发给专门的执行智能体——比如一个专门读取日历、一个专门起草邮件、一个专门查询CRM记录。这种并行结构大幅提升了执行速度，但也意味着单次目标触发的实际动作可能远超你的预期。你以为只是发了一封跟进邮件，背后可能有三个子智能体同时在读取你的收件箱、查询报价记录、并更新客户状态。这正是"第一版计划必须先审查"的底层原因：你需要看清楚的不是一个动作，而是一棵动作树。

智能体为自己的工作署名

公告里有个细节的分量超出表面：Google的"同事"智能体拥有自己的Workspace账户——独立的邮箱地址、日历、云盘，以及在公司通讯录里的存在感——还有一条归属于智能体本身（而非某个人）的审计记录。同事们像对待任何其他人一样与它协作。

剥掉品牌外壳，这其实是一套问责架构（accountability architecture）。当客户问"我为什么会收到这封邮件？"时，有一个可追溯的答案：源于哪个目标、哪些规则、哪次审批。如果你在任何技术栈上建立委派习惯，都要保留这个属性。每一个智能体的动作，都应能追溯回一份书面目标和经人类批准的边界。这正是让委派"站得住脚"而非"推诿不认"的关键——也是在供应商改变其他一切之后，唯一能存活下来的部分。

问责架构（accountability architecture）这一概念源于企业治理与合规领域，核心是确保每一个决策或动作都能被追溯到具体的授权人、授权范围和触发依据。在传统IT系统中，这通常通过访问日志和权限管理实现。将独立账户与审计记录赋予智能体，本质上是把这套机制从"人"延伸到了"软件行为者"。对小企业而言，这不只是技术细节——一旦智能体代表你向客户发送了一封措辞不当的邮件，或者错误地标记了一笔应收款，"我不知道它会这么做"并不构成有效的免责理由。能够回答"这个动作源于哪份书面目标、经过谁的审批"，才是在客户投诉或业务纠纷中真正能站得住脚的答案。

模型是组件，不是承诺

还有一个值得细想的公告细节：Google的智能体默认会为任务挑选最合适的模型，而用户可以覆盖这一选择——包括选用第三方模型，首批就支持Anthropic的Claude。Google的智能体，运行着Claude的模型，连接到Slack、Microsoft 365、Jira和Postgres。

对小企业的现实启示是：门上的那个logo，已经不再等于真正干活的那个模型，而且永远不会再是了。别再执着于挑选"正确"的模型。把精力投入到那一层比任何模型都更长寿的东西上——书面的目标、边界、以及审查计划的习惯。这些都能迁移到下个季度推出的任何新东西上。而总会有下一个季度。

什么时候该用目标模式，什么时候不该

目标模式在那些有清晰完成状态的重复性工作上最能发挥价值：跟进循环、评价回复、报告汇总、收件箱分流、排期轮次、供应商文书催办。而指令模式仍然适合一次性任务、新颖情境，以及任何"工作究竟怎么做"还没被写下来的事情。你无法为一个只存在于某人脑子里的流程委派目标。

最后这一点，才是真正的落地顺序：挑一个重复性工作流，写下它今天是怎么做的，把它变成包含三要素的目标，审查它产出的第一版计划，然后让它运行并每周抽查。一个工作流。这就是全部计划——无论智能体来自Google、Microsoft，还是一个20美元的自动化工具，这个计划都通用。