传统 Web 基础设施主要服务人类浏览器：用户点击按钮，服务器处理一次请求，再返回页面或 JSON。自主 Agent 改变了这个节奏。它们可能持续运行数小时，反复调用工具、保存中间状态，并在无人确认的情况下执行下一步动作。Agents Week 聚焦的核心问题，正是云基础设施如何从“响应人类请求”转向“承载自主执行”。
浏览器请求与 Agent 任务不是同一种工作负载
典型 HTTP 请求通常短暂、相对无状态，并且有人类用户处于交互回路中。Agent 任务则更像一个能够暂停、恢复和重试的工作流：
- 它需要保存计划、工具调用结果、模型输出和检查点。
- 它可能等待外部系统数分钟甚至数小时。
- 同一步骤可能因超时而重复执行，因此工具操作必须考虑幂等性。
- 它会动态决定下一次调用什么服务，执行路径难以提前完全枚举。
- 它可能代表用户操作敏感资源，但用户并不会确认每个动作。
这意味着“启动一个容器并让它一直跑”并不足以构成 Agent 原生基础设施。平台还需要明确任务身份、状态归属、恢复语义、预算限制和审批边界。
三类基础能力需要一起演进
存储：从会话数据变成可恢复状态
Agent 不仅需要保存聊天记录，还需要区分原始输入、工作记忆、长期记忆、工具结果和执行检查点。每份状态都应带有任务 ID、租户、版本和来源信息，否则重试时很难判断哪些结果可以复用。
对于会产生外部副作用的步骤，可以把“准备执行”和“执行完成”分别写入持久化存储，并为操作分配幂等键。这样即使工作进程崩溃，恢复程序也能判断某个动作是否已经提交。
执行：从请求处理变成可暂停的任务租约
Agent 执行器需要面对超时、进程退出和节点迁移。一个实用模型是任务租约：工作进程领取任务后定期续约；租约到期，调度器才允许其他工作进程接管。检查点则记录下一步从哪里继续。
执行环境还应限制 CPU、内存、运行时间、模型令牌和工具调用次数。自主性越强，预算越不能只是监控指标，而应成为平台可以强制执行的约束。
安全：授权对象是任务，而不只是用户
把用户的长期凭证直接交给 Agent，会让一次提示注入或错误规划获得过大的影响范围。更稳妥的方向是为每个任务签发短期、最小权限凭证，并分别控制网络出口、文件访问和工具权限。
高风险动作还需要独立的策略检查。例如读取日历可以自动完成，发送邮件可能需要内容审查，而转账、删除资源或修改生产配置通常应进入人工审批队列。
可以这样实践：构造一个最小任务执行边界
下面是一个概念性配置示例，并非来源中声明的真实产品 API。假设平台支持任务租约、检查点、预算和工具策略，可以先用类似 YAML 明确运行边界，再映射到现有的队列、容器平台和密钥系统。
apiVersion: agents.example/v1
kind: AgentTask
metadata:
name: invoice-review-2025-03
spec:
identity:
tenant: accounting
credentialTTL: 15m
execution:
leaseDuration: 60s
checkpointEvery: 5
timeout: 20m
maxRetries: 2
budget:
maxModelTokens: 50000
maxToolCalls: 30
storage:
checkpointURI: s3://agent-state/invoice-review-2025-03/
encryptWith: alias/agent-task-state
network:
defaultDeny: true
allowedHosts:
- api.accounting.internal
tools:
- name: read_invoice
permission: allow
- name: update_invoice_status
permission: require_approval
- name: initiate_payment
permission: deny
在真实系统中，执行器还必须在调用工具前再次校验策略，不能只相信模型生成的工具名称。下面的 Python 示例可以直接运行，用来演示“允许、审批、拒绝”三种决策；它只是策略边界示意，不是生产级沙箱。
from dataclasses import dataclass
from enum import Enum
class Decision(str, Enum):
ALLOW = "allow"
REQUIRE_APPROVAL = "require_approval"
DENY = "deny"
@dataclass(frozen=True)
class ToolCall:
task_id: str
tool: str
arguments: dict
POLICY = {
"read_invoice": Decision.ALLOW,
"update_invoice_status": Decision.REQUIRE_APPROVAL,
"initiate_payment": Decision.DENY,
}
def authorize(call: ToolCall) -> Decision:
return POLICY.get(call.tool, Decision.DENY)
def execute(call: ToolCall) -> None:
decision = authorize(call)
if decision == Decision.DENY:
raise PermissionError(f"tool denied: {call.tool}")
if decision == Decision.REQUIRE_APPROVAL:
print(f"approval queued for {call.task_id}: {call.tool}")
return
print(f"executing {call.tool} with {call.arguments}")
if __name__ == "__main__":
calls = [
ToolCall("task-42", "read_invoice", {"invoice_id": "INV-1007"}),
ToolCall("task-42", "update_invoice_status", {"status": "approved"}),
ToolCall("task-42", "initiate_payment", {"amount": 1200}),
]
for item in calls:
try:
execute(item)
except PermissionError as error:
print(error)
运行方式：
python agent_policy.py
生产实现还应记录策略版本、调用参数摘要、审批人和最终结果，并对参数执行模式校验，避免一个看似安全的工具通过危险参数越权。
落地时先回答这些问题
Agent 原生架构不一定要求推倒现有云平台。团队可以先在任务队列、对象存储、容器执行器和身份系统之上补齐控制面，但要明确以下问题：
- 任务中断后，从哪个检查点恢复，已经产生的副作用如何去重？
- 每个任务可以使用哪些工具、访问哪些主机，凭证多久失效？
- 谁为令牌、计算时间和外部 API 调用设置硬上限？
- 哪些动作可以自动执行，哪些动作必须审批，哪些动作永远禁止？
- 审计日志能否还原模型决策、策略判断、工具参数和执行结果？
真正的变化不是给现有应用接入一个模型，而是把自主任务当作新的基础设施主体。存储负责让它可恢复，执行系统负责让它可控制，安全层则负责限制它即使判断错误也只能在明确边界内行动。