扎克伯格在 Meta 内部会上承认，过去几个月 AI Agent 的发展没有按预期加速。这个信号值得开发团队认真看：不是 Agent 不重要，而是把它当成“马上能自我完成复杂工作”的万能组件，风险正在变高。尤其在巨额基础设施投入背后，真正难的不是多跑几个模型调用，而是让 Agent 在目标分解、工具调用、状态管理和错误恢复上稳定工作。
预期降温，不等于方向失败
从来源摘要看，核心变化是 Meta 对 AI Agent 的短期进展做了重新判断：发展轨迹没有像预期那样加速。这类表态的技术含义很直接：团队不能只用演示效果来判断 Agent 成熟度。
一个能在 demo 中“订会议、查资料、写邮件”的 Agent，离生产可用还差几层硬骨头：
- 任务边界是否清楚：Agent 是否知道哪些事能做，哪些必须交给人。
- 工具调用是否可靠：API 超时、权限不足、返回脏数据时怎么处理。
- 记忆和状态是否可追踪：一次长任务失败后，能不能复盘它为什么走偏。
- 成本是否可控：多轮推理、检索和工具调用会迅速放大 token 与基础设施账单。
Meta 级别的投入说明大厂仍在押注 AI 基础设施，但“押注基础设施”和“Agent 立刻成熟”不是同一件事。对普通工程团队来说，更合理的动作是把 Agent 项目拆成可测、可回滚、可审计的小能力。
Agent 最容易卡住的地方：不是模型，而是闭环
很多 Agent 项目一开始会把精力放在模型选择上：换更大的模型、换更长上下文、换更强的推理模式。但进入真实业务后，卡点常常出现在闭环系统里。
例如客服 Agent 需要查询订单、判断政策、生成回复、必要时创建工单。任何一步出错都会把用户体验拉垮。模型回答“看起来合理”并不够，系统还要知道：
- 它调用了哪个工具；
- 工具返回了什么；
- 它为什么选择这个动作；
- 它是否越权访问了数据；
- 它的最终输出是否满足业务规则。
这也是为什么短期预期需要降温。Agent 不是一个 prompt，而是一套带执行权的软件系统。只要它能写数据库、发消息、下订单或改配置，就必须按后端系统的标准来设计。
可以这样实践：给 Agent 加一个最小评测闭环
下面的例子不依赖特定云厂商，也不声称来自 Meta 内部实践。它展示的是一个团队可以采用的最小方法：把 Agent 的工具调用过程记录下来，并用测试用例检查它是否选择了正确动作。
把下面代码保存为 agent_eval.py，直接运行：
from dataclasses import dataclass
from typing import Callable, Dict, List
@dataclass
class Step:
tool: str
input: str
output: str
class ToyAgent:
def __init__(self, tools: Dict[str, Callable[[str], str]]):
self.tools = tools
self.trace: List[Step] = []
def run(self, task: str) -> str:
self.trace.clear()
# 这里故意用规则模拟 Agent 决策，真实项目可替换为 LLM function calling。
if "退款" in task or "refund" in task.lower():
result = self.tools["lookup_policy"]("refund")
self.trace.append(Step("lookup_policy", "refund", result))
return f"根据政策：{result}。建议转人工确认订单状态。"
if "订单" in task or "order" in task.lower():
result = self.tools["lookup_order"]("latest")
self.trace.append(Step("lookup_order", "latest", result))
return f"订单查询结果：{result}"
return "无法确认任务类型，转人工处理。"
def lookup_policy(topic: str) -> str:
policies = {"refund": "签收后 7 天内可申请退款，数字商品除外"}
return policies.get(topic, "未找到政策")
def lookup_order(order_id: str) -> str:
return "订单 latest 当前状态为已发货"
def evaluate() -> None:
agent = ToyAgent({
"lookup_policy": lookup_policy,
"lookup_order": lookup_order,
})
cases = [
{
"task": "用户询问退款规则",
"expected_tool": "lookup_policy",
"must_contain": "转人工",
},
{
"task": "帮我查一下最近订单",
"expected_tool": "lookup_order",
"must_contain": "已发货",
},
]
failures = []
for case in cases:
answer = agent.run(case["task"])
used_tools = [step.tool for step in agent.trace]
if case["expected_tool"] not in used_tools:
failures.append(f"{case['task']}: expected tool {case['expected_tool']}, got {used_tools}")
if case["must_contain"] not in answer:
failures.append(f"{case['task']}: answer missing {case['must_contain']!r}: {answer}")
if failures:
raise SystemExit("\n".join(failures))
print("All agent checks passed")
if __name__ == "__main__":
evaluate()
运行：
python agent_eval.py
这段代码很小，但它抓住了 Agent 工程化的三个关键点：任务输入、工具轨迹、可自动检查的期望结果。真实项目可以把规则决策替换成 LLM function calling，把 trace 写入日志系统，把测试集扩展成线上失败样本回放。
更像后端系统，而不是聊天窗口
如果团队已经在做 Agent，可以把发布标准从“回答不错”改成更硬的检查表：
- 每个工具都有权限边界和超时策略。
- 每次执行都有 trace id，能复盘完整调用链。
- 高风险动作默认需要人工确认，比如付款、删除、发外部邮件。
- 评测集包含成功样本、失败样本、越权样本和模糊意图样本。
- 成本监控按任务维度统计，而不是只看总 token。
- Agent 输出进入业务系统前，要经过规则校验或结构化 schema 校验。
这些要求听起来不如“全自动智能体”刺激，但它们决定了 Agent 能不能从演示走到生产。
采用建议：把野心放在路线图里，把权限关在笼子里
Meta 的表态提醒了一个朴素事实：AI Agent 的上限很高，但短期交付不能靠上限下注。团队可以继续投资 Agent，但最好从窄场景开始，例如内部知识检索、客服辅助、运维诊断、销售线索整理。这些场景有明确输入、明确工具、明确验收标准，失败后也容易回滚。
更激进的全自动流程可以保留在路线图里，但生产系统应先要求可观测、可评测、可限权。Agent 不是越自主越好，而是在正确边界内替人完成稳定、重复、可验证的工作。预期降温之后，真正有价值的工程会变得更清楚。