刚接触智能体的人，常在两处卡住：不知道该准备什么，也不知道搭到什么程度算完。其实可以按三步走：先弄清它要替谁做完哪件事，再把这件事拆成能跑的步骤，然后把它放到有人会用到的地方。三步各有明确的完成标准，不必等全学会再动手。

一、理解：先把"要办完的那件事"说清楚

这个阶段值得优先花时间。建议用一句话写下任务：谁、在什么情况下、要把什么变成什么。例如"采购岗每月把邮件里的需求与系统库存对照，算出缺口清单并发给计划员"。这句话里已经包含输入、处理与产物，后面的搭建都围绕它。

接不上的细节，用三个问题补齐：材料在哪里（邮箱、共享盘、某个系统）；按什么规则判断（阈值、优先级、例外）；结果给谁（写成表、发到群，还是回写系统）。三个问题答完，任务边界基本清楚。

判断这一步完成的标准也简单：把这句话和三个答案念给同岗位的同事听，对方能指出哪里不对，说明写具体了；对方只会说"差不多"，说明还太虚。

二、搭建：节点、规则与人工确认

搭建阶段不必一次做全。可行的顺序是先跑通一条窄路径：只处理一种输入、只走一条分支、只产出一份结果，然后再加分支与异常。节点可以简单理解为"能单独验收的一步"：取数、清洗、判定、生成、回写、通知。六步里每一步都要能回答：输入是什么、输出是什么、怎么判断它成了。

规则要落到字段与阈值上。凡是"看起来是否合理""差不多就行"这类判断，都要改写成可比对的表达式，否则每次跑出来都不同。定不下来的规则，先标为人工确认点，不要硬判。分支也要有默认路径，处理"条件都不满足"的情况，否则未命中就会被静默跳过。

选样本有个笨办法很有效：先找三份自己熟悉的真实材料跑一遍，把跑不通的地方记下来。跑不通的地方往往就是规则或字段没定义清楚的地方，比看一百页文档更直接。

设备维修知识检索问答就是这种结构：维修人员遇到故障时查检修资料，答案需要带来源引用，找不到依据就不能编造。这条链路里，检索与引用由系统接走，判断"这条结论能不能照着修"仍在工程师手上。分工写清楚，工具才不会被当成一个会瞎编的搜索框。

图 1：一条窄路径上的六个节点，每个节点都能单独验收

三、发布：先给一个人用，再给一个组用

发布不等于上线到全公司。可行的做法是先给一位同事用一周，观察三件事：他是否需要重新解释背景；结果是否需要他再誊一次；出错时他知不知道找谁。三件事都顺，再扩到一个小组。

发布形式按使用场景选：群里能直接问的，做成群内可调用的入口；需要在表格里持续产出的，挂成按触发运行的任务；需要在固定时间给出结果的，配成定时任务并约定通知对象。入口选错，能力再强也没人用。

发布时还要定两件事：失败时通知谁，以及结果发到哪里。前者决定出问题时能不能快点恢复，后者决定有没有人真的看到结果。这一步不是靠把消息到处发，而是靠把场景与渠道对上：群里的问答走消息入口，需要留存的产物放到文件与表格，需要回写的直接落到系统。

这一步不是靠功能多，而是靠入口对：Soiawork 把技能、工作流与自动任务放在同一处，搭好的方法保存成技能后，换一批数据、换一个人发起，只改输入不改口径；发布时选择触发方式与通知渠道，不用重新搭一遍。对新手而言，这种“先存方法再选入口”的顺序比先搭流程再补入口要省事得多。

图 2：方法保存成技能，发布时选择触发方式与通知渠道，入口跟着使用场景走

四、跑起来之后的三次检查

• 一周后：看失败次数与失败原因，判断是输入问题还是规则问题。
• 两周后：看有没有人主动复用，没人用通常是入口选错了，不是能力不够。
• 一个月后：看结果有没有被下游直接使用，仍需人工誊抄说明产物形态没定对。

三次检查之后通常要做一次调整：把反复出现的异常补进规则，把没人用的入口换掉，把需要人确认的点收窄。零基础起步的差别不在起步快慢，而在愿不愿意按这三步各验收一次。

三个月后再回头看，会发现真正被留下来的通常是那几条边界清楚、产物固定的任务；听起来宏大但说不清产物的，往往在第二次迭代就停了。起初那一条窄路径，反而是可以一直加宽的底座。

回头看这三步：理解是把事说清，搭建是把事拆开，发布是把事送到人手上。这条窄路径先跑通，再加宽，比一开始就设计一套大而全的流程更容易活下来。这也是 Soiawork 把技能与自动任务分开摆的考虑：方法与触发各改各的，一条窄路径才跑得久。