从 0 构建 AI Workload Platform（五）：Agent Runtime、工具权限与自然语言工作流

摘要模块 3 在已有的可靠工作流内核和控制面之上增加了从自然语言目标到结构化工作流草稿的入口。本文先展开一次完整流转再解释 Agent Runtime管理模型调用、工具权限和运行边界的 Agent 运行时、模型适配器、工具调用、权限、预算、草稿校验、内容哈希和人工确认如何协作。当前成果证明的是“生成可审核草稿经校验和确认后交给原有可靠执行链路”不是让模型绕过用户和控制面直接执行真实业务也不能证明真实模型的规划质量或生产可用性。目录本篇要解决什么问题先看一次完整运行过程Agent、模型、工具与 Runtime为什么不能让模型输出后直接执行工作流草稿为什么不是普通 WorkflowDefinition为任务增加结构化 Input只读工作流目录与工具注册表草稿校验为什么分层执行内容哈希与人工确认预算、重试、超时和取消稳定错误码与审计事件为什么选择 Mock Model 和 HTTP 适配器实际 CLI 流程测试和性能结果当前限制总结1. 本篇要解决什么问题AI Workload Platform 是一个正在从零开发的可靠运行时和调度平台。前面的模块已经能够校验 DAGDirected Acyclic Graph有向无环图、管理任务状态、处理重试与恢复并通过 HTTP 控制面和 PostgreSQL 保存工作流。到这里用户仍然必须手写结构化 WorkflowDefinition任务叫什么、执行什么 Action、依赖谁、输入参数是什么都要提前确定。模块 3 增加一条新的入口用户可以先描述目标由 Agent 生成结构化工作流草稿平台再检查任务、参数、依赖、权限、任务超时和 Agent Workflow 并发最后由用户明确确认。确认后的定义才能进入原有可靠执行链路。本篇会讲清楚Agent、模型、工具和 Agent Runtime 分别是什么为什么不能让大模型生成 JSON 后直接执行如何隔离模型供应商协议如何用工具注册表限制 Agent 能做什么为什么要区分事实、假设和待确认问题草稿校验、内容哈希和人工确认如何协作超时、取消、预算、重试和审计怎样形成运行边界当前实现已经验证了什么还没有解决什么。2. 先看一次完整运行过程先用一个固定的文档处理目标看完整链路用户输入先读取 article.md再清洗内容最后生成摘要模块 3 当前实现不会让模型直接读文件或执行命令。它只让模型发现平台登记过的任务模板然后生成一份需要审核的工作流草稿。一次运行按以下顺序推进阶段负责组件输入输出这一阶段不负责什么1. 接收目标Agent CLI / Runtime自然语言目标ModelRequest不创建 Workflow不启动 Run2. 发现能力Model Adapter 只读目录工具工具描述、查询参数任务模板和参数规则不执行文件、Shell 或网络操作3. 生成草稿Model Adapter Runtime目标和目录结果WorkflowDraft不把草稿当作已授权定义4. 校验草稿Draft Validator workflow.Compile任务、Input、依赖、权限和限制错误、警告和新哈希不替用户回答未决问题5. 人工确认agent confirm用户检查后的草稿和哈希WorkflowDefinition不写 PostgreSQL6. 保存版本模块 2 控制面最终定义、幂等 Key不可变 Workflow Version不由 Agent 绕过 API 写库7. 启动 Run模块 2 控制面Workflow ID、版本号、幂等 Key已持久化的 pending Run不把“保存定义”当成“开始执行”8. 执行任务模块 1 Engine已创建的 RunRun、TaskRun、Attempt 状态当前 Mock Executor 不执行真实文档处理因此模块 3 的“闭环”是从自然语言目标到可确认的结构化定义并把定义交给原有可靠执行链路它不是“输入一句话后自动完成真实业务”。后文的每个概念都对应这张表中的一个阶段。3. Agent、模型、工具与 Runtime3.1 什么是 AI AgentAI Agent人工智能智能体是一种围绕目标组织模型调用、上下文、工具和控制流程的软件系统。模型可以根据输入生成下一步建议Runtime 决定建议是否允许执行、执行哪个工具、什么时候停止以及如何记录结果。这一定义包含一个重要边界Agent 不等于大模型。大模型负责根据输入产生输出Agent 还需要软件层面的循环、权限、预算、取消和状态管理。例如用户输入先读取 article.md再清洗内容最后生成摘要。模型可以建议三个任务及其依赖关系但模型本身不应该自动获得读取文件、执行命令或修改数据库的权限。是否提供某个工具、工具允许哪些参数、调用失败后怎样处理都应由 Agent Runtime 控制。3.2 什么是 Model AdapterModel Adapter模型适配器是平台与具体模型服务之间的协议转换层。平台只依赖统一的请求和响应typeModelAdapterinterface{Generate(context.Context,ModelRequest)(ModelResponse,error)}不同供应商可能使用不同 URL、认证头、模型名称、错误结构和工具调用字段。适配器负责转换这些差异但不能把供应商 SDKSoftware Development Kit软件开发工具包的类型扩散到 Runtime、CLICommand-Line Interface命令行界面或工作流内核。这样做的价值不是让所有模型表现完全相同而是让上层稳定地处理几类平台语义模型返回结构化草稿模型请求调用工具模型服务暂时不可用响应格式错误调用超时或被取消。3.3 什么是 Tool CallingTool Calling工具调用是模型先返回“希望调用哪个工具以及参数是什么”再由应用程序决定是否真正执行的机制。模型提出请求不直接持有工具能力。一次典型流程如下Runtime 把允许的工具描述发给模型 - 模型返回工具名和 JSON 参数 - Runtime 检查注册、权限、预算和参数 - Runtime 调用工具 - 工具返回结构化结果 - Runtime 把结果交给模型继续生成如果 Runtime 收到未注册工具名正确行为是拒绝而不是根据名字猜测要执行什么。3.4 什么是 Agent RuntimeAgent RuntimeAgent 运行时环境是真正负责执行边界的组件。当前项目中的 Runtime 负责调用 Model Adapter只暴露注册过的工具限制模型轮数、工具次数、响应大小和总时长传递超时和取消解析结构化草稿记录模型、工具、校验和确认事件把错误转换为稳定机器码。工作流内核仍然负责 DAG 调度、任务状态、Attempt、重试和恢复。Agent Runtime 不重新实现调度器工作流内核也不解析自然语言。4. 为什么不能让模型输出后直接执行模型输出至少有四类不确定性。第一格式可能错误。JSONJavaScript Object NotationJavaScript 对象表示法是一种结构化文本数据格式模型响应可能不是合法 JSON也可能包含未知字段或超出大小限制。第二内容可能不完整。用户说“读取文档”但没有说明文件来源模型可能自行补成article.md。这个值可以作为假设展示不能伪装成用户明确提供的事实。第三权限可能越界。模型可能请求一个平台没有注册的工具或给只读工具传入命令、文件路径和外部 URL。第四结构正确不代表业务合法。即使 JSON 能解析仍可能存在未知 Action、缺少必填参数、循环依赖、任务超时过长或 Agent Workflow 并发超限。因此模块 3 使用以下强制路径自然语言目标 - Agent Runtime - Model Adapter - 受控工具调用 - Workflow Draft - 参数、权限、任务超时、Agent Workflow 并发和 DAG 校验 - 用户确认 - WorkflowDefinition - 控制面版本化保存模型输出只是候选草稿。结构校验、用户授权和可靠执行是三个不同阶段。5. 工作流草稿为什么不是普通 WorkflowDefinition最终的 WorkflowDefinition 只需要描述可执行结构Workflow ID、并发数、任务、Action、Input、依赖、重试和超时。但人工审核还需要知道“这些内容从哪里来”。因此草稿增加了以下信息WorkflowDraft - draft_id - goal - definition - facts - assumptions - questions - validation - tool_calls - status - content_hash - created_at - confirmed_at5.1 Facts用户事实facts保存直接来自用户输入的陈述。例如用户要求读取 article.md并按读取、清洗、摘要的顺序处理。这里的“事实”只表示来源是用户输入不表示平台已经访问外部系统验证内容真伪。这个边界必须明确否则“用户说过”和“系统核实过”会混为一谈。5.2 AssumptionsAgent 假设assumptions保存模型为了补齐草稿而推断的内容。例如清洗模式为 standard摘要上限为 200 词。假设不会自动导致校验失败但会产生警告并展示给用户。用户确认完整草稿时也是在确认这些假设。5.3 Questions待确认问题questions保存必须解决的缺失信息。每个问题有稳定 ID、问题文本、回答和是否解决的状态。只要仍有未解决问题草稿就不能确认。假设和问题的区别在于假设有一个可供审核的默认值问题缺少足以形成可执行定义的信息。哪些内容允许使用默认值应该由产品规则和任务模板决定而不是由模型任意决定。6. 为任务增加结构化 Input模块 1 的任务最初只有ActiontypeTaskDefinitionstruct{Key TaskKey ActionstringDependsOn[]TaskKey Retry RetryPolicy TimeoutMillisint64}仅有 Action 可以表达“执行 read-document”却不能表达“读取哪个文档”。模块 3 因此增加可选 JSON 对象Inputmap[string]anyjson:input,omitempty选择 JSON 对象有三个原因工作流定义本来就通过 JSON、HTTP 和 PostgreSQL 传递不同 Action 的参数不同统一固定结构会迫使所有任务携带无关字段任务目录可以为每个 Action 单独声明参数类型、必填项和枚举。代价是 Go 编译器不能在编译期检查每个 Input 字段因此 Runtime 必须按模板做运行时校验。Input 只允许 JSON 能表达的对象、数组、字符串、数字、布尔值和空值不允许函数、通道、结构体、字节切片、自定义 JSON 编码器、脚本或循环引用。这里不能只用“能否调用json.Marshal”作为判断因为结构体和字节切片也能被 Go 编码却不属于本项目约定的 Input 数据模型状态型自定义编码器还可能让两次编码得到不同结果。单个任务输入编码后最多 64 KiB。编译阶段会深拷贝嵌套对象Engine 再为每次 Executor 调用复制一份防止调用方或执行器修改共享定义。JSON 中的数字没有固定整数位宽。Go 默认把解码到any的数字保存为float64大整数可能因此失去精度。项目在 CLI、HTTP、Go 客户端、FileStore 和 PostgreSQL 恢复入口统一启用json.Number使9007199254740993这样的输入在确认、提交、加载和恢复执行后仍保持原值。旧定义没有 Input 时字段为空因此原有模块 1、模块 2 示例保持兼容调度和状态转换规则没有变化。7. 只读工作流目录与工具注册表7.1 目录里保存什么第一版工作流目录是进程内静态注册表每个任务模板包含模板 ID 和 Action参数名称、类型、必填项和枚举所需权限最大任务超时是否允许 Agent 使用。示例目录包含Action主要输入权限与超时上限read-document必填字符串source需要document:read最长 30 秒clean-document可选mode只能是standard或strict最长 30 秒summarize-document可选数字max_words最长 60 秒7.2 为什么目录工具必须只读当前目标是验证模型如何发现平台能力并生成工作流不是让模型执行任意操作。因此工具输入只有一个查询字符串{query:document}输入 Schema 不提供path、command、url、HTTP method 或 request body。未知字段会被严格拒绝查询最长 1024 字节返回值是目录内容的深拷贝。这比“在提示词中告诉模型不要执行危险操作”更可靠因为权限边界存在于代码接口和注册表中。提示词可以影响模型建议不能代替服务端授权。7.3 工具注册表如何拒绝越权每个工具注册时绑定所需权限typeRegisteredToolstruct{Tool Tool RequiredPermissionstring}当前调用顺序是Runtime 先建立单次工具超时 Context注册表再查找工具并检查权限通过后才进入目录工具。目录工具在查询前严格解析 JSON 参数拒绝未知字段、尾随内容和超长查询返回 Runtime 后Runtime 还会限制响应大小并记录审计事件。因此未知工具和缺少权限会在进入工具实现前被拒绝非法参数会进入目录工具的参数校验逻辑但不会真正执行目录查询。这两个拒绝位置不同但都不会获得文件、Shell 或网络权限。第一版工具白名单不是安全沙箱。它只能证明当前接口没有提供高风险能力未来新增文件、网络或代码工具时必须重新设计权限、隔离和审批规则。8. 草稿校验为什么分层执行草稿校验依次检查草稿标识和用户目标Agent 工作流并发是否不超过任务数和 32 的上限模块 1 的workflow.Compile是否接受标识、任务数量、重试和 DAG任务 Action 是否存在且允许 Agent 使用Input 必填项、类型、枚举和未知参数任务权限和模板允许的最大超时待确认问题是否已经解决Agent 假设是否需要给出警告。workflow.Compile仍是 DAG、标识符、任务数量和通用重试规则的唯一编译入口。Agent 校验器没有复制一套环检测算法。这样以后内核规则变化时结构化定义和自然语言草稿不会出现两套互相冲突的判断。校验结果一次返回全部错误和警告{errors:[],warnings:[{code:assumption_present,path:assumptions[0],message:Agent assumption requires user review}]}错误阻止确认警告要求用户注意但不一定阻止确认。机器读取稳定code用户阅读message字段位置由path指出。校验失败不是草稿的死路。用户可以修正参数或回答待确认问题再次执行validatevalidated和needs_confirmation状态都允许回到校验步骤。新报告和新内容哈希会覆盖旧值已经confirmed或明确rejected的草稿则不能回退。9. 内容哈希与人工确认9.1 哈希解决什么问题如果用户先查看草稿文件随后被修改而确认命令仍然接受旧的“是”那么用户确认的内容和最终输出可能不是同一份。模块 3 对审核内容的规范化 JSON 计算 SHA-256draft_id goal definition facts assumptions questions validation tool_calls status - canonical JSON - SHA-256 - content_hashSHA-256Secure Hash Algorithm 256-bit256 位安全哈希算法会把输入映射为固定长度摘要。这里使用它检测内容变化不用于加密也不用于隐藏原文。确认时比较三项用户命令传入的哈希草稿文件保存的哈希根据当前草稿重新计算的哈希。三者必须完全相同。之后 Runtime 还会重新运行目录校验和workflow.Compile防止审核后模板或规则已经变化。9.2 哈希不能证明什么内容哈希不是数字签名不能证明确认者身份也不能阻止有文件权限的人同时修改草稿和哈希。第一版目标是防止审核内容与确认内容无意不一致。未来进入多用户控制台后还需要把草稿版本、操作者身份、权限和审批记录保存在控制面数据库中。9.3 确认与数据库事务的边界事务Transaction是数据库把一组读写作为一个不可分割操作提交或回滚的机制。模块 3 的confirm只在本地重新计算哈希、校验草稿并输出 WorkflowDefinition不写数据库因此它本身不是数据库事务。用户随后调用模块 2 的workflow create时控制面才在 PostgreSQL 事务中保存幂等记录、Workflow 和不可变版本。确认成功不等于控制面提交成功如果提交失败可以使用相同幂等 Key 重试而不需要让 Agent 绕过控制面直接写数据库。这个分离使“用户审核了什么”和“平台最终持久化了什么”都能分别验证。10. 预算、重试、超时和取消Agent 循环如果没有停止条件模型可能不断请求工具或生成超大响应。第一版使用以下默认限制限制默认值作用模型调用轮数4限制 Agent 循环长度工具调用次数8防止工具调用失控单次模型或工具响应64 KiB限制内存和上下文增长Runtime 总时长30 秒为整个生成会话设置截止时间单次工具调用5 秒隔离卡住的工具context.Context是 Go 标准库用于传递取消信号、截止时间和请求级信息的接口。父 Context 取消后Runtime 不再发起新的模型或工具调用HTTP 适配器也使用同一个 Context 取消网络请求。只有标记为临时的模型传输或服务错误允许重试一次。结构错误、工具拒绝、参数错误、预算耗尽和草稿无效都不重试因为再次执行不会自动修正这些确定性问题。Runtime 的模型重试和工作流内核的 Task Attempt 重试不是同一层Runtime 重试处理一次 Agent 生成过程中的模型服务波动工作流 Attempt 重试处理已经进入执行阶段的任务失败。把两者混在一起会导致调用次数、费用和状态含义难以解释。11. 稳定错误码与审计事件Runtime 使用稳定错误码model_timeout model_unavailable model_invalid_response tool_not_allowed tool_invalid_input tool_timeout budget_exceeded draft_invalid approval_required draft_changed canceled这些错误码用于 CLI、测试和未来 HTTP API 判断行为不能依赖可能变化的人类错误文本。审计事件记录草稿生成开始与完成模型调用完成或重试工具允许或拒绝草稿校验用户确认内容哈希和非敏感结果分类。生成失败、取消和预算耗尽会统一记录draft.generation_failed并保存已经消耗的模型轮数和工具次数。终止事件使用不继承业务取消信号、但带短截止时间的独立 Context避免原请求取消后连失败原因也无法留下审计失败不会覆盖原始业务错误码。审计不是把所有输入原样写入日志。API Key、Authorization、Token 和密码字段会被替换为[REDACTED]。HTTP 适配器不记录完整 Endpoint避免查询参数中的凭证意外进入日志。当前审计接收器只保存在内存中适合测试协议和事件内容进程退出后不会保留。持久审计、指标和分布式调用链属于后续可观测性模块。12. 为什么选择 Mock Model 和 HTTP 适配器12.1 Mock Model 的作用Mock Model 用固定逻辑模拟两轮响应第一轮请求工作流目录第二轮返回三任务草稿。它使以下行为能够离线复现工具调用循环工具权限拒绝预算耗尽结构错误取消和超时草稿校验和确认。Mock Model 不评估真实模型的自然语言理解、推理质量或指令遵循能力。它验证的是平台协议和控制边界。12.2 为什么真实适配器先使用标准库 HTTP第一版真实适配器使用 Go 标准库net/http实现 Chat Completions 风格的 JSON 协议。Chat Completions 是按消息列表提交对话并接收模型回复的一类 HTTP 接口形式。JSON Schema 是描述 JSON 字段、类型、必填项和嵌套结构的规则请求用它约束 WorkflowDraft工具续轮则使用 assistanttool_calls和带tool_call_id的roletool消息。选择标准库实现的原因是当前只需要一个最小人工演示适配器可以明确控制超时、响应大小、错误分类和日志不把供应商 SDK 类型传入项目公开接口本地httptest.Server可以验证完整 HTTP 合约。携带 API Key 的远程 Endpoint 必须使用 HTTPS本机回环地址才允许 HTTP客户端不自动跟随重定向避免凭证被转发到另一个地址。不同供应商对工具调用和结构化输出的支持仍可能不同所以“本地协议测试通过”不等于“所有兼容供应商已经验证”。没有优先引入供应商 SDK是因为 SDK 会增加版本、类型和依赖绑定而当前没有流式响应、批处理或供应商专属能力需求。如果后续需要供应商特有的流式事件、Token 统计或重试策略可以在相同 ModelAdapter 后增加独立实现。12.3 为什么没有使用 LangChain 或 LangGraphLangChain 和 LangGraph 提供模型、工具和 Agent 编排能力适合快速组合复杂 AI 应用。本项目当前没有优先使用它们原因不是这些框架能力不足而是模块 3 需要直接展示并验证工具白名单在哪里检查预算在哪一轮消耗取消如何停止后续调用错误如何映射为平台语义草稿为什么不能直接执行。这些边界使用少量 Go 接口可以清楚实现并与现有 Go 工作流内核保持同一进程和类型系统。代价是项目需要自行维护模型循环和工具协议。以后出现复杂状态图、模型生态集成或 Python 工具链需求时应重新比较框架集成成本而不是永久排斥成熟框架。12.4 为什么没有先做多 Agent多 Agent 会增加角色分工、消息路由、共享上下文、重复工具调用、死循环和成本归属问题。单 Agent 的权限、预算、确认和审计尚未稳定时多 Agent 只会扩大不确定性。当前自然语言草稿由一个 Agent 完成普通程序任务仍是一等能力。只有真实场景证明单 Agent 无法满足职责隔离或并行协作需求时才引入多 Agent。13. 实际 CLI 流程创建本地演示目录并生成草稿mkdir-p.workload/agent-demo go run ./cmd/workload agent draft\先读取 article.md再清洗内容最后生成摘要\--modelmock\--output.workload/agent-demo/draft.json校验草稿go run ./cmd/workload agent validate\.workload/agent-demo/draft.json\--output.workload/agent-demo/validated.json读取哈希并确认DRAFT_HASH$(jq-r.content_hash.workload/agent-demo/validated.json)go run ./cmd/workload agent confirm\.workload/agent-demo/validated.json\--hash$DRAFT_HASH\--output.workload/agent-demo/workflow.json实际输出的最终定义包含{id:agent-document-pipeline,concurrency:1,tasks:[{key:read,action:read-document,input:{source:article.md},retry:{max_attempts:1},timeout_ms:30000},{key:clean,action:clean-document,input:{mode:standard},depends_on:[read],retry:{max_attempts:1},timeout_ms:30000},{key:summarize,action:summarize-document,input:{max_words:200},depends_on:[clean],retry:{max_attempts:1},timeout_ms:60000}]}confirm只输出定义不创建 Workflow也不启动 Run。在控制面已启动且WORKLOAD_SERVER_URL和 operatorWORKLOAD_TOKEN已导出的终端中首次保存这份不可变定义go run ./cmd/workload workflow create\.workload/agent-demo/workflow.json\--idempotency-key agent-demo-workflow-v1这个命令修改 PostgreSQL创建agent-document-pipeline的 Workflow Version 1但仍不会开始执行。使用相同请求和幂等 Key 重放时会返回同一结果如果该 Workflow 已由其他请求创建应直接使用已有版本不要换一个幂等 Key 重复创建同一 ID。然后显式创建并启动一次 Rungo run ./cmd/workload run start\agent-document-pipeline\--version1\--idempotency-key agent-demo-run-1这个命令先在 PostgreSQL 中创建 pending Run事务提交后再交给 Engine 后台执行。当前控制面使用 Mock Executor因此 Run 可以展示状态流转但不会真正读取article.md、清洗内容或生成摘要。14. 测试和性能结果默认测试不访问外部模型覆盖模型、工具、草稿、校验、确认、HTTP 合约和 CLI。HTTP 适配器使用本机测试服务器模拟 429、非法响应和取消不需要真实 API Key。本机 Apple M4、Go 1.26 环境下运行五轮基准平均结果为场景五轮平均Mock 草稿生成16.726 微秒/次草稿校验7.531 微秒/次三模板目录查询869.86 纳秒/次已取消请求快速返回并记录失败审计923.12 纳秒/次这些结果说明当前本地控制逻辑没有暴露毫秒级固定开销但不能推导真实 Agent 的响应时间。真实模型延迟主要受推理、网络、供应商排队、限流和输出长度影响通常远大于这里测量的本地 JSON 和校验成本。当前分配量仍有优化空间Mock 生成约 21.8 KiB、180 次分配草稿校验约 12.0 KiB、123 次分配。已取消请求约 1.9 KiB、15 次分配增加的开销来自失败审计事件和短时审计 Context它换来取消原因与预算快照不会丢失。主要分配来源还包括 JSON 编解码、嵌套 Input 深拷贝和草稿哈希。当前路径不在高频任务调度热循环中因此先保留清晰边界和正确性证据后续只有在实际负载证明它成为瓶颈时再优化。15. 当前限制模块 3 已经证明Agent 可以通过受控模型和只读工具生成结构化草稿平台可以区分事实、假设和待确认问题未知工具、权限不足、参数错误、任务超时、Agent 并发超限和 DAG 错误会被拒绝草稿必须校验并通过内容哈希确认确认后的定义仍由可靠工作流编译器处理默认测试无需网络和付费模型。模块 3 完成时仍有以下限制Mock Model 只支持固定文档处理示例不代表通用自然语言规划能力HTTP 适配器通过了本地合约测试但尚未记录某个外部供应商的真实调用结果审计事件没有持久化人工确认仍是 CLI 和 JSON 文件不包含多用户身份与数据库审批记录目录是静态内存数据不支持动态注册、版本和租户隔离CPU、内存和临时存储尚未进入任务定义它们要等模块 6 的真实执行环境统一设计和验证最终控制面仍使用 Mock Executor不会真的读取、清洗或摘要文档当时没有多 Agent、多 Worker、容器任务环境或 Web 控制台工具白名单不是任意代码安全沙箱。这些限制决定了模块 3 的成果是“可靠 Agent 边界和自然语言草稿闭环”不是完整商业 Agent 平台。后续模块 4 已经增加独立 Worker、租约和故障接管模块 5 已经增加日志、指标、Trace、告警和可重复故障实验受限执行环境和最终控制台仍待后续建设但都不能绕过本篇建立的工具权限、结构校验和人工确认规则。为什么下一步进入模块 4模块 3 解决的是“怎样把自然语言目标变成受控、可确认的结构化定义”没有改变任务实际执行位置。确认后的 Run 仍由控制面进程中的 Mock Executor 推进因此增加更多 Agent 功能也不能解决执行节点扩容、Worker 失联、任务重新分配和旧结果覆盖新结果的问题。模块 4 随后把任务执行拆到独立 Worker使用 PostgreSQL 持久化待分发事实Worker 通过 HTTP 按空闲容量主动领取用租约带过期时间的任务执行权和心跳Worker 周期发送的存活与续约请求判断临时执行权再用隔离令牌标识当前合法租约、用于拒绝旧写入的值拒绝旧 Worker 的迟到结果。这里继续复用模块 2 的数据库和网络边界是为了先验证多进程所有权不同时引入消息队列、新的流式通信协议或 Kubernetes。实际验证也确认了对应代价轮询请求、数据库分发压力和租约过期后的重复执行可能仍然存在因此模块 4 保持“任务不能静默丢失但可能重复”的至少执行一次语义不承诺任务在任何故障下都只执行一次。没有先做真实文件、Shell 或容器工具是因为任务副作用一旦真实发生Worker 故障后的重复执行会更难判断和清理没有先做 Kubernetes部署和管理容器化应用的开源平台是因为 Kubernetes 可以重启进程却不会替平台判断某个 Attempt 的租约是否有效。先把执行所有权和迟到结果规则验证清楚模块 5 才能系统观察这些故障模块 5 已经完成这一步模块 6 才适合加入真实受限执行环境。16. 总结把模型接入工作流平台关键工作并不是发出一次 API 请求而是建立可控制、可替换、可取消、可审计的执行边界。模块 3 将自然语言目标转换为可审核草稿用 Model Adapter 隔离供应商用工具注册表限制能力用任务目录校验 Action 和 Input用预算与 Context 限制循环再用内容哈希和人工确认阻止草稿直接执行。最终定义继续进入原有 Compiler 和控制面Agent 没有绕过可靠工作流内核。这条路径保留了模型的生成能力也保留了工程系统需要的确定性边界。真正的生产 Agent 还需要持久审批、真实工具隔离、外部模型评测和多节点执行这些能力必须在已有证据上逐步增加不能用“模型足够聪明”代替权限和可靠性设计。参考资料Gocontext官方文档https://pkg.go.dev/contextGoencoding/json官方文档https://pkg.go.dev/encoding/jsonGonet/http官方文档https://pkg.go.dev/net/httpOpenAI Function Calling 官方说明https://platform.openai.com/docs/guides/function-callingOpenAI Structured Outputs 官方说明https://platform.openai.com/docs/guides/structured-outputs项目源码本文对应模块 3。完整源码、Mock 演示和后续模块见 AI Workload Platform GitHub 仓库。