最近复盘企业级 Agent 落地的工程设计时，最有体会的不是“多个 Agent 怎么协作”，而是协同发生之前那个更具体的问题：客户现场报了个 P0 故障，用户登录失败率从 0.3% 突然涨到 11%，原因不明。Agent 能不能从这条工单出发，自己一步步缩小范围、自己决定要不要读生产配置、自己在该停下来时找人审批，最终交出一个能被验收的修复？

这个问题比“让几个 Agent 坐在一起讨论”难多了。难点不在协作，而在没人能提前画出这次任务的执行图：Agent 跑完第一步看日志，才知道第二步该查认证还是查数据库；跑完第三步看接口返回，才决定要不要申请读生产 token 缓存的权限。

编排式工作流引擎擅长在确定的 DAG 上调度任务，但它们都假设“下一步是谁、用什么参数”可以提前编排好。Agent 任务正好相反：每一步是什么、用什么工具、传什么参数，都是模型当场决定的；同一张工单跑两次，调用路径都可能不一样。这种运行时不可预知性才是 AgentOS 真正要消化的东西。

本文借用 AgentOS 这个说法，指的是为了承载这种非确定性智能体而需要的运行底座：它要让 Agent 在做选择时被记录、被约束、被恢复，而不是放任模型在真实系统里漫游。

一个边跑边决定的智能体，如果连自己跑到第几步、用了哪些工具、为什么选了某个动作都说不清，多 Agent 协同只会让这种不确定性互相放大。

落地时最容易炸的不是模型不会写代码，而是模型“边想边动手”带来的四个断点：

登录失败率突增排查（每一步都由模型当场决定）
├── 状态散在聊天里         → Agent 跑了 30 次工具调用、40 分钟，
│                            重启后 prompt 复读不回中间结论
├── Runtime 跑错环境       → 模型决定要看生产配置，
│                            但执行机器根本没在客户 VPC 里
├── 工具权限靠 prompt      → 模型现编 shell 参数，
│                            prompt 里写的"别读 .env"挡不住它
└── 过程没有 Timeline      → 跑完一次几乎不可复现，
                              客户问"它当时为什么读了那张表"答不上

四个断点的共同根源都是同一件事：模型每一步都在做选择，但选择本身没有被系统接住。要让这种执行体在企业里跑得起、停得下、说得清，AgentOS 要给运行时不确定性配齐五个对应物：

AgentOS 任务闭环 = TaskRun + Runtime + Context Contract + Guardrail + Timeline

TaskRun           接住"步数不可预知"——任务可以跑半小时、可以中途等审批、
                  可以从语义摘要恢复，状态机不能假设线性结束
Runtime           接住"模型会要求新能力"——执行环境要先把自己能做什么
                  声明清楚，再让调度器决定这次任务能不能给它
Context Contract 接住"prompt 不是程序"——任务材料、工具白名单、验收标准
                  用结构化文件落盘，让模型的执行边界可测试
Guardrail         接住"工具参数是模型现编的"——每一次真实动作发生前
                  由系统规则判定，而不是寄希望于模型自觉
Timeline          接住"推理过程不可复现"——把每一次选择、每一次拦截、
                  每一次审批都写进可回放的事件流

少一层都会出问题——任何一层薄了，模型每一次决策都会少一种约束。

工单不是 prompt，是 TaskRun

企业任务不是一句话问答。客户 P0 缺陷里，业务真正关心的是：谁发起、哪个客户、哪个仓库、哪个版本、谁审批、产物在哪里、失败后能不能继续。

所以第一步不是“调度多个 Agent”，而是把所有入口统一成 TaskRun。

客户群消息
Issue 创建
监控告警
Webhook 触发
   │
   ▼
入口适配器
   │
   ▼
TaskRun
   ├── status: queued / claimed / running / waiting_approval / succeeded / failed
   ├── source: issue / chat / webhook / alert
   ├── actor / customer / workspace / agent_version
   ├── runtime_selector
   ├── policy_snapshot
   ├── acceptance_criteria
   └── timeline_events

这个设计看起来不性感，但它决定了后面能不能运营。任务能不能查询、恢复、取消、重试、审批、审计，靠的不是更聪明的模型，而是有没有把“这件工作”明确记录下来。

另一件容易被忽略的事：TaskRun 创建时要把当时生效的配置冻结一份。同一个 Agent 今天能读 A 仓库，明天权限收紧；今天工具允许写文件，明天改成只读——如果任务执行时总读“当前最新配置”，事故发生后没法解释它当时为什么能做某个动作。所以 execution_policy_snapshot、security_policy_snapshot、runtime_selector 这几个字段都应该在 enqueue 之前 freeze 一次，任务后续即使跑了一小时，也按当时这份快照执行。

一个简单判断标准：异常执行发生后，只能查到“现在的 Agent 配置”、拿不到“当时这次任务按什么规则执行”的系统，还没到可审计状态。反例是把所有配置都挂在 Agent 当前版本里——短期实现最快，长期排查最痛，客户问“为什么它当时能读这个路径”，不能回答“可能那会儿配置不一样”。

不适合这么做的场景也有：如果只是临时问答，没有工具调用、没有产物、没有审批和审计要求，那 Chat 就够了。别为了架构完整性硬上任务系统，反而会把简单问题做重。

让 TaskRun 经得起断线

不少人把任务队列理解成“发个消息给执行器”。这个理解在短任务里问题不大，但 P0 缺陷处理经常不是短任务。

它可能要读文档、检索仓库、调用 MCP、生成补丁、等待审批、继续执行。中间 Runtime 会断线，Provider 会卡住，负责人会取消，服务也可能重启。这个时候队列不只是发通知，而是在回答一个很实际的问题：这件事现在到底归谁处理，多久没动就要收回来。

落到系统里，可以用这样的状态流转来表达：

queued
  │ claim(runtime)
  ▼
claimed ── start(provider) ──▶ running
  │                              │
  │ lease expired                │ tool needs approval
  ▼                              ▼
queued/retry                  waiting_approval
                                 │ approved / denied
                                 ▼
                             running / failed

running ── final result ──▶ succeeded / failed / cancelled

Runtime 领取任务前，平台至少要检查四件事：它是否在线、是否还有并发容量、是否被授权访问这个客户工作区、是否满足任务要求的 Provider 和安全等级。

def claim_next_task(runtime):
    if not runtime.is_online():
        return None
    if not runtime.has_capacity():
        return None

    candidates = task_store.find_queued_tasks(
        workspace_ids=runtime.authorized_workspaces,
        customer_ids=runtime.authorized_customers,
        limit=50,
    )

    for task in candidates:
        if runtime_can_execute(runtime, task):
            task.status = "claimed"
            task.runtime_id = runtime.id
            task.lease_until = now() + runtime.lease_ttl
            task.attempt += 1
            task_store.save(task)
            return task

    return None

租约解决的是一个具体问题：任务已经被拿走，但执行机器失联了怎么办。Runtime 执行过程中持续续租；租约过期后，平台可以重排，也可以标记失败交给人处理。

不要用同步 HTTP 请求硬扛长任务。看起来少了一张表，实际是把“任务到底有没有继续执行”藏到了连接超时、进程重启和用户刷新页面里。

Runtime 不是命令路径

一些早期实现会把 Runtime 理解成一个 CLI 路径，比如“用某个命令跑 Codex”或“用某个命令跑 Claude Code”。这个理解太薄了。

客户现场任务里，Runtime 更像一台被平台登记和管理的执行机器：它在哪个客户环境，能访问哪些仓库，有没有 MCP Proxy，有没有 File Guard，支持不支持 session resume，最大并发是多少，这些都要稳定上报给平台。

一份有用的 Runtime 信息可以保持得很简单：

{
  "runtime_id": "rt_customer_a_01",
  "customer_scope": ["customer_a"],
  "workspace_scope": ["workspace_prod_support"],
  "mode": "customer_vpc",
  "status": "online",
  "supported_providers": ["codex", "claude", "custom"],
  "capacity": {
    "max_concurrency": 2,
    "running": 0
  },
  "capabilities": {
    "mcp_proxy": true,
    "file_guard": true,
    "session_resume": true,
    "plugin_driver": ["bundle", "native"]
  },
  "guard_level": "mcp_proxy",
  "last_heartbeat_at": "2026-05-22T10:20:30Z"
}

调度器拿到这份信息后，才能判断某个任务是否应该交给它。任务不是随便找一台机器跑，而是要匹配客户授权、工作区授权、Provider 能力、并发容量和安全要求。

反例是“Runtime 只要能启动 Provider 就行”。这样做本地 demo 很快，进入企业部署会立刻被环境差异拖垮：有的任务必须在客户内网，有的任务必须访问本地仓库，有的任务不能让文件离开 VPC，有的任务必须走企业代理。

Runtime 内部还要有一层 Driver 来消化模型侧的差异。Claude、GPT、自研模型在工具调用语义、会话恢复粒度、token 计价口径上各不相同，Driver 把这些差异挡在统一事件流之前，平台只看消息、工具调用、用量和最终状态。第一版图省事，把某个模型的日志格式或会话参数直接灌进任务模型，第三个模型接进来时就开始还债。

上下文不要全塞进 prompt

不少 Agent 系统会把所有内容都塞进 prompt：工单描述、客户信息、项目说明、工具列表、权限限制、历史记录、输出格式。短期看实现最快，长期看最难维护。

更稳的方式，是把上下文拆成几份结构化文件。prompt 只表达任务意图，真正的执行边界由文件承载。

一个典型工作目录可以这样组织：

work_dir/
├── context/      # 9 份结构化任务材料，承载执行边界（详见下图）
├── artifacts/    # 本次产物（补丁、报告、生成文件）
└── logs/         # 执行日志与事件流

这个目录不是数据库表的镜像，而是平台和 Runtime 之间约好的任务材料包。只要这份材料包稳定，Runtime 不需要理解后端内部模型，Provider 也不需要读取平台数据库。

安全上下文可以像这样落盘：

{
  "enabled": true,
  "mode": "enforce",
  "runtime_requirements": {
    "min_guard_level": "mcp_proxy"
  },
  "tool_guard": {
    "enabled": true,
    "denied_tools": ["shell.destructive", "network.exfiltration"]
  },
  "file_guard": {
    "protected_paths": [".env", "secrets/**", "private/**"],
    "deny_operations": ["read", "write", "delete", "archive"]
  },
  "approval": {
    "require_for": ["external_write", "production_change"]
  }
}

这个设计还有一个隐含好处：策略、工具暴露和执行边界都变成了可以测试的对象。可以对 security.json 写单元测试，也可以在 Runtime 领取前做能力校验，而不是把边界埋进一段不可验证的自然语言里。

什么时候不该这么拆？如果系统只有一个 Provider、没有工具代理、没有多入口，也没有安全要求，那这套文件约定可能是过度设计。先把 prompt 拼接规则收敛好就够了。等开始接第二个 Provider 或第二类 Runtime，再拆成稳定的任务材料包也不迟。

prompt 不是权限边界

Agent 进入客户现场工作流后，安全问题会从“回答是否可靠”变成“动作是否被授权”。

只在 prompt 里写“不要读取敏感文件”“不要执行危险命令”“不要上传凭证”，不能算权限边界。模型可能误解，也可能被工具输出诱导，还可能被用户输入绕过。可靠的边界应该落在真实执行动作之前，由系统规则来拦。

一次执行的有效策略通常来自多个地方：

策略来源	解决的问题	不该放在哪里
工作区角色	谁能发起任务	Agent instructions
Agent 版本	这个 Agent 适合做什么	Runtime 本地配置
工具规则	哪些工具能用、哪些要审批	工具 description
文件规则	哪些路径不能读写	prompt 提醒
Runtime 要求	必须在哪类环境执行	用户输入
预算与审批	高风险动作怎么停下来	Provider 原生日志

比较稳的做法，是在任务创建或领取时把这些来源合并成这次任务的有效策略。Runtime、MCP Proxy、File Guard 和平台 API Guard 都读同一份策略快照，这样同一次任务里的判断口径才一致。

准入判断可以很直接：

def runtime_can_execute(runtime, task):
    policy = task.security_policy_snapshot

    checks = [
        runtime.status == "online",
        runtime.has_capacity(),
        task.workspace_id in runtime.authorized_workspaces,
        task.customer_id in runtime.authorized_customers,
        runtime.supports(task.required_provider),
        runtime.guard_level >= policy.runtime_requirements.min_guard_level,
    ]

    return all(checks)

这段逻辑背后的原则是：执行环境要先证明自己有能力，再参与调度。权限控制不应该等工具调用时才开始。任务已经进入不受控环境后，再补日志就只是事后追踪。

MCP Proxy 是工具关口，不是装饰

MCP 让 Agent 接工具很方便，但工具越强，风险越高。文件系统、代码仓库、数据库、浏览器和企业 API 都可能带来数据泄露或破坏性操作。

直接把原始 MCP Server 暴露给 Agent，其实就是把安全边界交给模型自觉。更稳的做法，是生成托管 MCP 配置，让所有工具调用先经过代理。

{
  "mcpServers": {
    "filesystem": {
      "command": "agent-mcp-proxy",
      "args": [
        "--task-id", "task_p1_123",
        "--policy", "./context/security.json",
        "--upstream", "filesystem-mcp-server"
      ]
    }
  }
}

代理读取任务目录里的 security.json，检查工具名、参数和调用上下文。命中允许规则再转发；命中告警规则就记录风险后继续；命中审批或阻断规则，就返回受控错误，并把决策写入 Timeline。

def handle_mcp_tool_call(server_name, tool_name, arguments, task_policy):
    intent = ToolIntent(
        name=f"{server_name}.{tool_name}",
        arguments=arguments,
        subject="mcp_tool_call",
    )

    decision = security_engine.evaluate(intent, task_policy)
    record_security_decision(decision.redacted())

    if decision.action "allow":
        return forward_to_raw_mcp_server(intent)

    if decision.action "warn":
        publish_warning(decision)
        return forward_to_raw_mcp_server(intent)

    if decision.action == "require_approval":
        create_approval_request(decision)
        return deny("waiting_for_approval")

    return deny("blocked_by_security_policy")

这里不要只做工具黑名单。真正的风险经常藏在参数里。同一个 shell，执行 npm test 和读取 .env 是两件事；同一个文件工具，读 README.md 和打包 secrets/ 也不是一个风险等级。

一个安全决策记录至少要能解释“为什么挡”：

{
  "action": "block",
  "severity": "high",
  "rule_key": "FILE_SECRET_READ",
  "subject_type": "file_path",
  "subject_ref": "protected_path",
  "reason": "blocked by protected path rule",
  "redacted_input": {
    "path": "protected_path",
    "credential": "***REDACTED***"
  }
}

说白了，Guardrail 不是为了把 Agent 管死，而是为了让授权变得可控。没有边界，Agent 很难进入真实系统；边界太粗，Agent 又做不了事。

过程回写比最终答案更值钱

模型每一次跑同一条工单，走的路径都可能不一样：先查认证还是先查数据库、读哪份配置、什么时候触发审批，都是当场决定的。这种不可复现的推理过程，只回传一个最终 result 远远不够，企业要看的是它为什么这么走、中间调了什么工具、哪些动作被拦截、用了多少 token、失败时卡在哪一步。

所以 Runtime 应该把执行过程按统一格式记录下来。

{
  "task_id": "task_p1_123",
  "events": [
    { "type": "message_delta", "content": "正在读取客户现场日志..." },
    { "type": "tool_call", "tool": "repo.search", "input_digest": "hash:6fd2", "latency_ms": 842 },
    { "type": "security_decision", "action": "warn", "rule_key": "EXTERNAL_WRITE" },
    { "type": "artifact_created", "path": "artifacts/patch.diff" },
    { "type": "approval_requested", "approver": "owner_42", "reason": "production_change" },
    { "type": "usage", "model": "gpt-5.5", "input_tokens": 18320, "output_tokens": 2140 },
    { "type": "final", "status": "succeeded" }
  ]
}

这条 Timeline 同时服务三类人：客户看它知道任务有没有推进，管理员看它知道风险动作发生在哪里，Agent 工程团队看它知道 Runtime、工具和策略到底哪里掉链子。

这里也有边界：不要把所有原始输入都塞进日志。工具参数里可能有 token、password、authorization、secret 之类的字段，审计前必须先脱敏。不然审计系统会变成新的敏感信息聚集点。

先闭环，再上 Teams

企业做 Agent 能力平台，最容易跑偏的顺序，是一上来就追求自动拆任务、自动评审、多个 Agent 互相讨论。听起来很酷，但底座没稳时，这些能力会放大混乱。

更稳的演进顺序通常反过来。

第一版先跑通单 Agent 任务闭环。客户 P0 缺陷能从 Issue 或 Chat 创建任务，任务能进队列，Runtime 能领取并执行，消息、工具调用、产物和最终结果能回写，失败原因和用量能被查看，用户也能取消、重试和验收。

第二版把 Runtime 纳入管理。执行环境不能只是“某台机器上有个命令”，而要能注册、心跳、离线检测、授权、声明能力、控制并发。管理员能看到哪些 Runtime 在线，哪些任务正在跑，哪些环境能执行某类任务。

第三版稳定上下文文件和 Provider Driver。工具、技能、仓库、策略和任务输入都按文件拆开，Provider Driver 只读取这份任务材料包，不读取平台数据库。新增 Provider 时，主要工作集中在文件读取、启动适配和事件转换，而不是改动整条任务链路。

第四版再把安全管控前置。任务级策略快照、Runtime 领取前能力校验、MCP 托管代理、文件访问规则、危险命令规则、高风险审批、安全发现和审计事件，都应该随着真实工具接入一起上线。

第五版才适合引入更复杂的 Agent Teams。Leader 负责派发和收敛，Member 负责专业执行，任务时间线承载协作记录，系统负责防止重复触发和协作循环，关键节点保留人工确认。

这个顺序的好处是，每一版都能独立验收。反过来做也不是不行，但会很快遇到一个尴尬问题：Agent 之间聊得很热闹，但没有人知道任务到底处于什么状态，也没人知道哪个动作应该被允许。

回到 Agent Teams 那个问题

如果一个 Agent 任务说不清楚“谁发起、谁执行、在哪执行、用什么权限、过程怎么回放、失败怎么恢复”，那大概率还不适合直接升级成 Agent Teams。

这些工程判断还没有展开所有细节，比如多 Agent 协作里的循环检测、预算控制、人工审批体验和 Provider 会话复用。

回到 FastAGI，这就是我们采用的最佳实践：先把 TaskRun、Runtime、Context Contract、Guardrail 和 Timeline 做成稳定的 AgentOS 任务闭环，再把 Leader / Member 分工、专业 Agent 协作和自动评审放到这条闭环上。真正值得继续追的问题不是“能不能让多个 Agent 一起聊”，而是：当 Agent 进入客户现场、内部系统和真实交付流程后，FastAGI 能不能让每一步都可执行、可解释、可追回。