把 Agent 当团队来管：五个月构建的企业级 SOP Agent 平台

引言

企业不缺会干活的 Agent，缺的是让 Agent 干活的管理方式。

把 Agent 当脚本管，流程拆到每一步、动作写死，它的判断力就废了；完全放开不管，它的事故又没人兜底。我们开发了一套智能体平台——SAF（SOP Agent Platform），走的就是第三条路：像和真人协作一样管理 Agent。你不会给资深员工写逐步操作手册，只需要讲清目标、划出边界、给足知识，验收成果就够了。对 Agent 也一样：过程交给 Agent Loop 自主运转，人守在边缘的检查点上。

框架对代码里的循环负责，平台对业务里的事故负责。

最看重的五件事

我们理解的企业需要，是一套可以放心委托的信任模型：业务本体划边界、审批流管高危动作、质量门禁验收交付物、预算治理控成本、全程留痕可对账。企业敢把一类业务交给 Agent，靠的是这些，而不是部署规模。

SAF 是我们 CAF（Common Agent Framework）的演进。五个月成长为后端约 18 万行、前端约 5 万行、近 3000 项自动化测试的规模。下面针对企业需求场景下的成果怎么算合规又如何验收、流程管到哪里、规则怎么生效、出了问题怎么继续——下文一 一判断。

一、先看全景：六层一张图

SAF 自下而上六层：

分两半读：

• 下三层（资源层到内核）是”框架”：声明式资源、执行引擎、工具系统，对开发者说话。
• 上三层（治理层到应用层）是”平台”：门禁审批、控制台、长期应用，对业务人员说话。
• 中间的服务层把两边接起来，REST + WebSocket 把内核的每次状态变化实时送到界面。

控制台不仅仅是个Agent控制平面。平台还提供本体工作台（对话式建模业务本体）、知识库管理（文档摄入 + 图谱编辑）、交付物库（血缘追踪）、审批中心，背后都是针对企业场景下的需求应对。模型接入不设限，可在同一个流程里不同步骤可以用不同模型，考虑成本与效率。

上图是 SOP 设计工作台：左边是设计助手对话，中间是流程画布，脚本、条件分支、Agent 三类节点各司其职，Agent 节点上直接标着角色、技能和 Token 预算；右边是流程属性，管理着编排方式（串行 / 并行 / DAG）和 对应的步骤角色与技能。

二、先说清楚，什么叫”做完了”

看一个真实跑过的任务。输入只有一句：

分析一下程序员未来的出路

没有任何定制代码，平台通过预先定义的流程、角色和技能，把这句话编排成十四页演示文稿。

这个案例能说明流程可以运行、最终有产出；对企业使用而言，更要紧的是内容可靠：判断有没有依据，结论与材料是否一致，大纲遗漏了什么，哪些是事实、哪些只是推测。这些说不清楚，自动生成十四页和自动生成四十页，价值差别可能很小。

所以 SAF 把交付物放在任务管理的中心。一个步骤需要提交可检查的文件或结构化结果，后续环节围绕它验收、交接、修订和追溯。Agent 在对话里声称完成，只是提交了完成意愿；成果是否受理，还要经过检查。

没有交付物的”完成”，只是 Agent 说它完成了。

交付物是价值流动的原子单位：质量门禁验收它，审批放行它，知识沉淀来自它，追溯链的节点也是它。

这也改变了流程的设计顺序。我们先问最终需要什么成果、怎样判断它合格，再倒推必要的阶段、角色和工具。”完成调研”很难验收；”关键判断附有可追溯来源，事实与推断分开，材料不足处明确标注”，就更接近一份可以执行的约定。每个步骤的验收标准必须是可判定的条目，不是”质量良好”这种空话——从”Agent 觉得做完了”，变成”标准说做完了”。

这里有个不太讨巧的事实：如果人还说不清怎样验收，增加 Agent 数量通常只会增加产出，不会自动增加可信度。

交付物库里，文件树按步骤组织：深度调研交了笔记，汇合出了汇总，报告落成简报，任务收口留下运行报告。点开任意一份，预览、血缘、版本随行——每个交付物带着完整身份：哪个任务、哪个步骤、哪个角色、哪次执行产出，版本之间有修订链。出了问题，可以从结果一路回溯到”哪个角色在哪个环节、基于什么输入、产出了什么”。

三、流程管到哪里，应该随着 Agent 的能力调整

设计 Agent 流程，容易走向两个方向。

一个方向是把每个动作都写死：先搜什么，再读什么，最后按固定格式输出。这种方式容易控制，但也容易让 Agent 退化成昂贵的脚本执行器。材料变了、问题变了，它仍被要求沿着旧路径走。另一个方向是给出目标后完全放手。短任务可能有效，长任务则容易出现失焦、重复探索和成本失控，等结果出来，才发现最初的理解已经偏了。

平台以交付阶段组织流程：流程声明阶段职责、依赖、输入输出和验收要求，节点内部怎样收集材料、怎样比较方案、怎样使用工具，尽量留给 Agent 判断。SOP 不是 BPM。 传统流程管理把每一步拆成确定性指令，前提是执行者没有判断力；Agent Loop 有判断力，而且上限在快速上移。流程的颗粒度应当贴着能力上限设计：管”交付什么、交到什么标准、哪里需要人确认”，不管”具体怎么做”。

这个边界需要持续调整。模型越能独立完成完整工作，流程就越没有必要替它规定细小动作；但涉及授权、成本和结果受理的边界，仍由系统明确执行。

边界往哪边调，也照应企业的一个现实：不少场景必须自己部署模型，数据不出域是硬约束，而可私有化的模型能力通常弱于前沿模型。相对低智的模型上放养一个 Loop，指令跟不住、工具用不稳、跑几步忘了目标，结果很难预期。SOP 的价值在这里再次显形：模型弱，结构补。交付物契约写具体些，检查点放密些，技能把方法写细些，关键位置加人审——可控性不必押在模型智商上。同样的流程，换个强模型可以放宽颗粒度，换个弱模型可以收紧约束，业务沉淀不跟着模型绑定。

同时，确定性工作应该继续由代码承担。SOP 支持三类步骤混编：

• Agent 步骤：Loop 自主执行，交付文件或少量机器输出（封闭字段表，严格校验）。
• Script 步骤：内联 Python 程序，同步入口 main(context)，不创建 Agent，不进自动返工。
• Condition 步骤：单谓词二选一，读任务输入或上游已受理的输出，路由到两侧分支，可选单汇合。

设计一个流程时，我们会反复问：这一环节真的需要模型判断吗？多加一个角色，是否带来了独立价值？两个步骤之间有没有值得交接的成果？如果没有，把它们拆开可能只是在增加协调成本。

编排管步骤，角色管判断。

SOP 表达静态步骤与依赖，节点内部的方法与决策交给执行角色。编排越权干涉判断，就退回了硬编码的老路。

四、可复用的首先是工作约定

很多 Agent 应用把提示词、工具权限、业务知识和当前任务揉在一起。第一次实现很快，但下一次需求稍有变化，就需要重新整理整套上下文。平台把其中相对稳定的部分拆成三层资源：Skill 是能力，Role 是岗位，SOP 是作业流程。三者都是一等资源，可版本管理、独立复用、整包流转；一次任务再提供具体目标、数据与限制。把组织里稳定的东西（能力、岗位、流程）建模成资源，把每次任务里变化的东西（数据、输入、细节）留给任务本身——大多数 Agent 系统把这两样搅在一起，所以每次新任务都像第一次。

4.1 Skill：把专业方法和工具一起打包

Skill 回答”怎么做”。一个技能定义一类专业任务的方法、知识与工具使用，并写清四件事：何时采用、如何操作、怎么判断结果好坏、失败时如何诊断修正。写不出这四点的技能，只是 Prompt 片段的堆砌。技能同时声明自己的工具白名单：文件技能只绑定文件工具，调研技能绑定搜索与抓取。能力边界跟着能力走，不散落在代码里。

4.2 Role：职责、思考方式和验收标准

Role 回答”谁来做、做到什么程度”。角色定义里分量最重的两项：

• 决策风格（decision_style）：面对问题时关注什么、如何取舍。工程角色”从目标和约束比较可行实现，选择复杂度与收益相称的方案”；研究角色”证据先于结论，区分事实、推断和不确定性”。它直接影响执行中每一步的判断质量。
• 质量门槛（quality_gates）：可判定的验收标准，例如”关键结论有可追溯证据，假设与不确定项明确”。我们给角色设计立了一条禁令：禁止”认真负责”“遵循最佳实践”这类空话，标准必须能核对。

每个角色在界面上都有自己的肖像。角色可见，责任才可见：任务详情页里”界定需求”挂着产品经理、”设计制作”挂着设计师，出了问题，知道该追查哪个角色的定义、技能与决策历史。

4.3 SOP：组织协作的四条原则

SOP 回答”怎么协作”：阶段职责、输入输出、前置依赖、验收标准。设计方法是从目标与最终交付倒推必要阶段。

这个拆分的价值，要到第二次、第三次执行才看得清。如果报告总是缺少证据，应该检查调研技能和验收要求；如果结论总是过度保守，可能需要调整角色的决策取舍；如果上下游反复误解，则应该检查交接契约。问题因此有了相对明确的修改位置，不必每次都往总提示词里追加一段要求。

一份流程声明同时是业务文档、执行规范、权限边界、编排声明、审计基准。改流程不用改代码，改声明；业务专家看得懂、改得动，审计员拿它对账。

不过，声明式资源只是让修改更容易，并没有免除设计责任。一份写着”认真负责、深入分析、遵循最佳实践”的角色定义，很难帮助执行者做取舍，也很难帮助审查者判断结果。资源文件能被加载，和它能改善工作，是两回事。我们更关心这样的定义：证据冲突时如何处理，信息不足时何时停止推断，什么缺陷必须返工。这些约定才是复用的实质。

平台里流动的东西也是一等公民：资源包、交付物、本体、知识各有独立的视觉身份。二十余种内置工具和成百上千个产出物在系统里流动，辨识度就是效率。

资源按”资源包”（Package Scope）组织，可整包导入导出。演示文稿任务用到的角色、技能和流程都在一个包里，导出发给同事，导入即用。

五、业务规则不能只靠模型”理解一下”

企业任务里有一类错误尤其隐蔽：文字读起来没问题，业务含义却错了。业务说”结案”，Agent 理解成对话结束；”确认”到底是保存草稿还是产生正式效力、某个例外该由谁批准，这些词在不同组织里可能有完全不同的含义。多放几份文档进上下文，有助于模型理解，却不能自然形成一致、可追溯的业务基线。

这些核心约定在 SAF 里是业务本体（Business Ontology）：结构化、可校验、可交付的业务包。本体是业务的核心域，也是业务的骨架，Agent 的每一次判断和行动都长在这副骨架上。业务包包含：

• 模型契约：每个业务模型（如界面、流程、报表、对象、行为、规则）有独立的内容 Schema、层级与引用关系。
• 业务说明：对每个模型的业务解释、理由、正常与异常路径、未决事项。
• 需求基线：经人工确认的正式需求。

理解它的一个框架是三层世界观：领域知识（术语、规则、数据）、能力边界（能做什么）、行为规范（异常怎么办）。本体包承载业务是什么、规则是什么；”能做什么”由技能白名单声明，”遇事怎么办”由流程的审批门与质量标准声明。本体不直接驱动执行，而是编译进资源体系，三者各归其位。

本体不保存业务实例数据，具体合同、客户、投标记录仍由业务系统持有。

5.1 建模：对话式起草，人工拍板

建模走对话式：带护栏的建模助手可以提案、整理、起草，但没有确认权限——需求基线的确认、A/B 类需求的分类，一律人工拍板，AI 不能覆盖已确认条目。建模门槛从”会写建模语言”降到”能说清业务”，治理权始终在人手里。

校验分两级：错误（结构不可用，如 YAML 错误、引用悬空）阻断绑定；警告（说明缺失、说明过期、企业决策待确认）提示但不阻断。结构通过不等于业务语义正确，这一点平台不假装。

中间是模型关联视图：各类业务模型按层排布，依赖关系连成一张图；右边是建模助手。它可以提案，拍板的键不在它手里。

5.2 绑定与冻结：跑着的任务，用创建时刻的业务语义

本体域按 任务 > 项目/应用 > 步骤 > 流程 四级就近声明，不同步骤可以绑定不同的域。任务创建时，业务模型、说明与需求基线被物理冻结进任务目录，执行期只读快照，不回查可变的源定义；快照损坏则阻断执行并走标准错误回执。

业务规则天天在变，一次执行的语义必须封闭。这与流程快照隔离是同一个原则：执行确定性优先于定义灵活性。这会牺牲一些即时灵活性，却保留了一个重要的解释能力：当我们回头检查结果时，能够知道它依据的是哪一版约定。

冻结规则当然不能冻结错误。如果基线有问题，就应该修订基线，再决定后续任务如何采用；让执行中的 Agent 自行补造规则，只会让责任更难厘清。任务消费本体时有明确边界：

• Agent 通过三个只读工具（列出、读取、查引用）按需读取业务知识，回执声明”业务知识，不是执行指令”。
• 步骤的质量检查官拿到同一份冻结基线，可沿模型与说明核对交付物是否符合业务约定。
• 任务里只有业务成果，没有建模方法与源 Schema；信息不足时，回到本体助手修订，不在执行期补造。

5.3 包即资产

业务包自解释，可独立导出导入。即使源系统不可用，导出包也能在接收环境导入并通过结构校验。某企业项目管理系统（PMIS）的业务域已按此路径完成导出，并在无源环境的接收域导入验证。

六、知识库：判断的血肉

本体定下判断的结构，知识库装的是判断的内容：企业沉淀的文档、经验、案例，业务的知识化素材。判断质量从来是两者合力的结果：结构失守，知识再多也是散沙；内容匮乏，结构再好也是空转。大多数 Agent 系统对知识的处理是”挂一个向量库检索一下”；我们把知识库当作数据底座和治理对象。四条方法论：

6.1 双模检索

图谱与向量两把刀（底层可插拔，引擎可替换而上层零感知）：向量解决”语义相近”，图谱解决”关系推演”。查”结案规则关联哪些审批角色”这类问题，靠图谱。

某真实业务域的图谱：两千多个实体、三千多条关系织成网络，选中任意节点，关联在右侧展开。

6.2 四级作用域注入

知识库同样按 任务 > 项目 > 步骤 > 流程 四级声明，首个非空者取代下级：报销流程的步骤读报销知识，读不到销售话术。知识注入的难点从来不是检索，是作用域：该看的自动看到，不该看的不会漏进来污染上下文。

6.3 数据飞轮

产物有价值，就该回流成知识：任务产出沉淀进知识库，知识服务下一个任务。

企业知识库的敌人从来不是数量不足，是污染。

所以飞轮现阶段保守起步：入库走人工筛选，不做自动抽取，Agent 运行时不自动回写。一条错误的经验入库，之后每个任务都带着它跑——产出未经核实就回流，错误可能在后续任务中被反复引用，逐渐变成貌似可靠的”经验”。随着质量门禁与交付物评价成熟，沉淀会逐步自动化，这是明确的方向。保存更多内容很容易，维护一批值得继续使用的内容，需要持续投入。

6.4 写入单入口

知识库是核心资产，质量由人来把关。机制上，执行中的 Agent 对知识库只读（写操作在 Worker 进程内被显式拒绝），写入只有一条路：主进程的治理接口，加人工确认。回写只有两条人工路径：图谱编辑，以及第七节的交付物沉淀。

七、审查降低风险，也带来新的成本

SAF 将执行与审查分开。可以由程序判定的格式和规则，先做确定性检查；需要理解内容的部分，再由独立的检察官 Agent 对照验收要求检查；审查结果交给质量门禁规则处理，决定受理、返工或转人工。

1. 机器检查在前：格式规则校验与脚本校验，确定性、可复现。
2. 独立检察官 Agent 在后：对照验收标准逐条审查，只报问题与严重度，不打分。
3. 质量门禁（确定性代码）按严重度加权算分，过阈值放行；任何一项严重问题强制返工。

评分与放行是有意分离的：评分的不管放行，放行的不参与评分，单点权力在任何系统里都是风险。还是那个演示文稿任务：第一个步骤提交大纲时，六条验收标准逐条核验，质量分 1.0，过 0.8 阈值。

这里的”独立”指职责和执行上下文分开，并不意味着审查者天然正确。两个 Agent 可能犯相似的错误，模糊的验收标准也可能让执行与审查一起自洽——把问题汇总成一个分数，仍然不能把这个分数当成客观质量的完整表达。因此审查必须尽量面对具体成果和证据：能通过脚本验证的部分，不必交给模型猜；高风险判断，保留人工介入的位置。

我们还要区分两类失败：成果本身不合格，以及检查器没有正常工作。前者可以要求返工；后者应处理审查故障或交给人判断——让执行者反复重做，无法修复一个失灵的检查器。

人工是按需出现的检查点。审批门不是每步一审，只在这些位置出现：配置了人审的步骤、返工次数耗尽、质检器异常、恢复耗尽、需要追加预算。审的是交付物，不是过程。任务级还可选执行策略：manual（全部待人）、gate（合法候选自动通过、其余待人）、unattended（无人值守，无法合法处理的待决转明确失败终态，不挂起）。无人值守不保证业务成功，只保证不卡死、不越权。

这些机制都有代价：额外调用、等待时间、流程维护，以及人工处理异常的精力。所以治理应该跟着风险走——一份个人草稿和一份将进入正式业务流程的材料，没有必要承担相同的审查成本。

沉淀为知识，闭环收口。 优质交付物经人工筛选进入知识库，成为后续同类任务的来源。

这个闭环也是三个模块的咬合点：

本体是骨架，固定业务语义；知识库是血肉，提供判断依据；交付物是证据，留下判断的痕迹。

八、长任务的难点：跑偏不可知，代价不可控

长任务真正的难点，不是跑不完，而是两件事：不知道它什么时候跑偏，以及结果不可预期时代价太高。一个 Agent 可以忙上四十分钟，方向早就偏了，人要到拿到结果才发现；而一次跑偏的执行，浪费的不只是 token 和时间——错误顺着流程流下去，返工跟着放大。

SAF 把长任务切成节点，针对的正是这两个难点。每个节点收一次口：交付物在这里验收，门禁在这里把关，配置了人审的在这里等审批。跑偏不需要等到终点才暴露，最多一个节点的距离，下一个检查点就把它拦下来；代价也切成了分段，坏结果最多坏一个节点，返工不必全盘重来。这也是 SOP 价值的落点：裸的 Agent Loop 也能跑完长任务，但没有检查点，跑偏要等终点才暴露，代价一坏就是整单；SOP 用节点把过程切成一段段可验收的里程碑，Loop 的自主留在节点内部，跑偏与代价都圈在节点边界。人在 Loop 中的位置，是像做项目一样守里程碑。

8.1 两级隔离

• 上下文隔离在步骤级。 每个 Agent 步骤的对话上下文独立，下游拿到的是上游已受理的交付物和状态台账，不是上游的完整对话。就像接手的工程师读交接文档，不读前任的聊天记录。上下文不随任务长度膨胀，审查有边界，一个节点内的混乱不会顺着对话流进下游。
• 进程隔离在任务级。 每个任务跑在独立的 Worker 子进程里，故障、资源、安全三重隔离：一个任务崩溃不拖垮主进程和其他任务；崩溃后自动检测并恢复，恢复次数有上限，超限转人工。

8.2 节点之内：一个循环足够

节点内部交还给 Loop：所有 Agent 跑在同一个执行引擎上，SDAO 循环（Sense-Decide-Act-Observe）。用循环做执行是当前 Agent 系统的共识，工程细节见另一篇文章。我们多做的一步是验证：v1 同时实现了六种范式（Direct、InlineLoop、ReAct、Plan、Reflection、思维树），结论与业界一致：范式的多样性是负担，一个循环足够。

它们的价值并没有丢，而是换了位置：Plan 成了循环内的计划管理动作，自我反思对应制度化的质量门禁，多路径探索对应并行子任务委派。多样性应当来自声明式资源，不来自执行引擎。

循环里三个反直觉的设计：

1. 上下文压缩而非无限累积。 两层压缩：先对老旧工具结果渐进截断，再在阈值处用 LLM 摘要。压缩后的锚点钉入确定性事实，包括已写入文件的工作集与最新版本、当前计划快照、最近的失败记录，摘要说错了也覆盖不了这些事实。
2. 终止即工具。 任务终止不是系统硬编码事件，而是模型主动调用”提交完成”。终止权在模型，不在框架。
3. 状态落盘，暂停安全。 节点状态变更即写权威状态文件；步骤内对话在工具批次后保存快照。暂停在节点边界与循环检查点生效，崩溃后已完成节点不重做，步骤从同一会话世代的快照续跑；没有可信快照时显式转人工，不静默重做。

但恢复有一个必须谨慎的地方：恢复对话，不等于撤销已经发生的外部动作。如果 Agent 已经修改文件、调用接口或提交操作，重新执行就可能产生重复副作用。接入业务系统时，仍需要识别哪些动作可以安全重试，哪些需要幂等控制，哪些必须先核对外部状态。

8.3 接入外部 Agent：Claude Code 与 Codex 也服从同一套契约

Loop 之外，平台还能把外部 Agent（Claude Code、Codex CLI）作为外援请进编排：它们在同一个 SOP 步骤里执行，服从同一套预算记账、交付物契约、安全拦截与事件流。各家的协议和预算机制差异，通过一张能力声明表显式承载（如 Token 预算是”提示性”还是”硬控”），下游只按声明分支，不假设一致——不把提示性的限制写成硬保证，也不让外援游离在管理之外。

8.4 治理的最后一层：成本

预算治理用租约制：每次 LLM 调用先拿租约，结束按真实用量结算；并发压力在治理器内排队，不产生审批。预算耗尽走唯一的”预算耗尽”通道进入暂停态，可恢复，授权追加后继续，而不是散落成各种失败分支。这让人能区分：是工作做不下去，还是当前授权的资源已经用完。限制分两层：

任务详情页：左边是步骤视图，每步的状态、评分、耗时都在卡片上——所谓”进度以节点为单位可见”，就是这排卡片；右边成本面板把”钱”摊开：总消耗、预算用了多少、哪个步骤花了多少。预算治理不是后台默默生效的机制，是一本可以随时翻开的账。

九、留下记录，是为了能改进下一次工作

B 端上 Agent 绕不开三个问题：它知道什么、它能做什么、它做了什么。

关于”能做什么”，需要诚实地说一句：命令黑名单、写目标边界、受保护文件校验这些静态检查，是防误操作层，动态构造的命令可能绕过；真正的隔离边界由沙箱后端承担（docker 为容器级隔离），事后由事件、文件副作用台账和 Git 历史追溯。我们不用扩充黑名单来假装拥有操作系统级权限。

9.1 事件流：执行记录完全透明

平台里发生的每件事都是一条事件：步骤启动、工具调用、质量评分、审批放行、状态变更。状态类事件先存再发：发射之前，权威状态已落盘；追踪事件全量写入事件日志，写失败进入显式降级告警，不静默吞掉。

透明不是把日志翻出来看，而是执行本身就是一条可回放的事件流。

任务跑着时，事件实时推到控制台；任务跑完后，完整记录仍在，可以逐事件回放。出了问题，回放就是取证。

9.2 双存储对账

状态文件是权威源，SQLite 是查询投影，两者由事件同步对账；投影丢失可由权威源重建，源文件缺失则不靠投影补造。界面里的一个状态，永远不会反过来成为另一份事实。

9.3 双视角词表

同一件事，开发者看到工程视角（节点状态、重试、进程通信），业务人员看到使用视角（”内容准备完成，产出脚本已入库”）。一套事实，两套语言，审计时各取所需。

这些设计最终服务于具体问题：结论由哪个步骤产生、用了哪些上游材料、哪次修改引入了问题、系统当时为何允许它继续。能回答这些，才有机会把一次失败转成明确的修正：改技能、改角色、改规则，或者修执行机制。

十、从任务到应用：复用要落到载体上

一次性任务跑完就散，是大多数 Agent 系统的现状。SAF 的最后两级台阶，是让任务沉淀下来。

• Project：持续改进同一份交付物。 对话式澄清需求、选定 SOP、迭代执行，项目有自己的阶段状态机（需求 → 方案 → 执行，可回流）。关键设计是同一项目的所有迭代共享同一份交付物目录：不拷贝，演进连续，版本靠修订链与 Git 标签追溯，同一时刻只有一个迭代在跑。这与 fork 的”每轮一份拷贝”是两种不同的协作模型。
• App：反复运营同一类业务。 应用模板声明关联流程与输入，实例化后可反复发射任务；Task 就是一次应用运行，没有第二套运行模型。实例有权威账本，同一实例同一时刻至多一个活跃任务（执行槽准入）。配套的 Assistant 是只读的辅助驾驶：帮你理解现状、判断方向、起草下一轮目标，但没有业务写权，也不会自动发射，发射由人确认。App 还冻结了一张对外 API 面（31 个端点，幂等 / 乐观锁 / 事件消费五纪律），平台因此可作为能力底座被外部系统调用。

任务的产出进交付物库、优质知识沉淀进知识库，Project 与 App 让这些积累的受益方，从”单个任务”变成”长期业务”。平台的价值也要在反复执行中体现：准备工作是否减少，成果是否更容易验收，异常是否更容易处理，成功经验是否真的可以复用。

十一、边界与演进：用结果回答

先讲不适合的场景——排除法比推荐更直接，也更容易对号入座：

1. 你要的是个人智能体工具。 WorkBuddy、OpenClaw 那类”一句话让 AI 像同事一样交活”的桌面工作台，拿来即用、个人提效，是条好路线，但不是我们的方向。同样一句”帮我做份 PPT”，通用工具给你一次交付；SAF 把它落成可复用的流程资产：角色、验收标准、审批门、知识沉淀都在，下个月同类的活直接再发射一次。个人日常办公选通用工具更划算；组织里反复发生的业务运转，才是 SAF 想接的活。
2. 你的流程无法结构化表达。 SOP 的前提是流程可声明：步骤、角色、验收标准说得清楚。探索性、无固定路径的工作，单一 Loop 加自由委派更合适（平台也支持，是另一套用法）。
3. 你只想要几分钟出效果的随手验证。 治理和沉淀在这个阶段是额外负担，先用轻量工具跑通想法；需要留痕、审批、复用时再来。

同时命中下面三条的场景，是平台的目标用户：

• 业务流程跨两个以上系统，且高风险动作需要人工节点；
• 有明确规则可以结构化表达（合规、财务、运营是典型）；
• 同类任务会反复跑，你想一次定义、长期复用。
• 对交付质量有明确的要求与验收标准的任务。

关于数据：平台、本体、知识库与执行数据都是私有化部署，留在你的环境内，全程不出域，配置本地模型，平台对此是一等支持。

演进的重心是企业级任务闭环：

前面讲的闭环——从任务发射到执行、审查、沉淀、复用——在单个组织内已经完整跑通。接下来的重心，是让这个闭环能走进企业的 IT 体系：不只在自己的控制台里跑，也能被其他系统调用。正在锻造 API Gateway——把”发射任务、订阅事件、取回交付物”变成标准服务接口，让别的系统把活交进来、把结果取走。

本体语义编译器仍是值得押注的长期方向：业务专家用自然语言描述需求，平台编译出流程、角色与执行约束，定义新流程的门槛从”会写声明文件”降到”会描述需求”。它的第一阶段能力——AI 辅助生成资源定义、对话式本体建模——已经在当前版本里；完整形态放在路线图后段，不与当前的重心抢道。

接下来，衡量这套机制的标准应该越来越具体：任务受理率、人工介入原因、返工次数、恢复结果，以及包含审查成本在内的单次交付成本。五个月让我们建立了一套可以继续验证的工作机制，它是否值得长期使用，要由真实业务中的重复运行来证明。

“把 Agent 当团队来管”，对我们而言，是认真对待委托之后的每一件事：给它什么依据，允许它做什么，用什么成果交接，出现异常由谁处理。最终希望得到的是这样的工作状态：一个人把任务交出去后，可以离开一会儿；回来时能看懂进展，核对成果，并在必要时接得住。

如果你想亲手看看——跑一个真实任务，看看质量门禁、审批流和交付物血缘是怎么运转的——或者你也在琢磨同样的问题，欢迎留言交流，或联系我。

相关文章

• 给 B 端一套知道边界的智能体框架
• 本体范式转移：从 Prompt 工程到本体工程
• Palantir 的 AI 范式与本体启示
• Agent Harness 工程：七个月的技术底座复盘
• Harness Loop 深度解析
• 后 AI 编程时代的工具全景