最近吴恩达在 No Priors 播客说了一句话，我反复想了好几天：
"The bottleneck in Agentic AI is no longer writing code. It's figuring out what to build and how to make agents actually work in production."
这话放在两年前说，是废话。放在今天说，是一记实实在在的警钟。
我们正处在一个奇怪的转折点：LLM能写代码了，Agent框架一大堆，工具链成熟了一大截——但企业里真正跑起来的Agentic系统，屈指可数。不是技术不够，是另外一种能力出了问题。
这篇文章想讲清楚：Agent落地的真正瓶颈在哪，"智能体部署与管理者"这个新职能是怎么冒出来的，工程师该怎么看待这场变化。
一、Agentic AI的瓶颈悄悄换位了
2023年GPT-4刚出来那会儿，大家最担心的是：模型能不能准确理解任务、能不能可靠调工具、能不能稳定输出结构化数据。这些是真实的技术挑战，大量的工程时间都花在这上面。
两年过去了，这些问题没有完全消失，但它们已经不是最难的那个。
Sebastian Raschka在他的《Components of A Coding Agent》里梳理了一个Coding Agent的核心组件：
Coding Agent
├── Planner # 任务分解与优先级
├── Code Generator # 代码生成/修改
├── Executor # 沙箱执行
├── Verifier # 输出验证（测试/静态分析）
├── Memory # 上下文管理（短期/长期）
└── Orchestrator # 多步骤协调与回滚
技术层面，这些组件已经有成熟的开源实现。问题出在哪？出在这个框架之外。
真正的难题是：
• 这个Agent要解决的到底是谁的问题？边界在哪？
• 它上线之后谁来监控？出了错谁来兜底？
• 怎么衡量它在生产环境里"够好"？90%的准确率算成功还是失败？
• 业务方怎么知道可以信任它到什么程度？
这些问题没有一个是纯技术问题。它们是产品问题、运营问题、组织问题。
而大多数工程师团队，包括那些技术非常强的团队，对这类问题完全没有思维框架。
二、一个新职能正在浮出水面
AI西经东译EP81里有一期聊的是企业里正在催生的新职能：智能体部署与管理者（Agent Deployment Manager / Agentic Operations Lead）。
这个Title在两年前根本不存在。现在一些走得快的公司已经在悄悄招了。
这个岗位到底干什么？简单说：
• 不负责写Agent本身的代码
• 负责定义Agent应该解决什么问题、边界在哪
• 负责建立评估体系，量化Agent在生产环境中的表现
• 负责在Agent出错时设计降级策略和人工兜底流程
• 负责向业务方解释Agent的能力边界，管理预期
听起来是不是有点像产品经理？是的，有相似之处。但又不完全是。传统PM不需要理解推理模型的行为模式，不需要设计prompting策略，不需要懂得什么时候该上ReAct、什么时候该用LATS。
它更像是一个混合体：有工程背景，但把精力重心放在了"让Agent在现实中活下去"这件事上。
我的判断是：这个职能在未来两年会大量涌现，而且不会是独立岗位——它会以"工程师 + Agent运营能力"的形态存在，嵌入在每一个做Agentic产品的团队里。
三、Agent在生产中究竟会遇到什么
光说抽象概念没意思，讲几个实际场景。
场景一：任务边界模糊导致级联失败
一个代码审查Agent，任务是"review PR并给出建议"。工程师认为任务很清晰，但在生产里跑了一周后发现：
• Agent有时候会直接修改代码，而不是给建议
• 有时候把安全告警当成代码风格问题忽略掉
• 有时候对同一段代码给出截然相反的建议
这不是模型能力问题，是任务定义和验证机制缺失的问题。
场景二：评估体系缺失，好坏无从判断
这是最常见的困境。Agent上线了，跑着，但是：
• 没有量化指标衡量它做得好不好
• 只靠用户反馈（而用户不反馈）
• 模型升级后，不知道是变好了还是变差了
一个可行的评估框架应该包含：
# Agent评估的四个维度
1. Task Success Rate
- 自动化指标（单测/集成测试覆盖）
- Ground Truth对比（有标注数据时）
2. Reliability / Stability
- 相同输入的输出一致性
- 跨时间的行为漂移检测
3. Boundary Behavior
- 遇到超出能力边界的任务时，是否正确拒绝/降级
- 而不是硬撑着给错误结果
4. Human Handoff Quality
- 需要人工介入时，移交信息是否够用
- 人工能否在5分钟内接管？
场景三：多Agent协作中的信任传递问题
ArXiv本周有篇论文很值得关注：CoopEval，专门评测LLM Agent在囚徒困境等博弈场景中的合作行为。
结论很反直觉：推理能力越强的模型，在需要合作的场景里反而越不合作。
原因大致是：强推理模型更善于计算对方的"预期背叛概率"，然后率先选择防御性策略。这在一轮博弈里是理性的，但在多轮协作任务里会导致整个系统陷入纳什均衡的次优解。
这对多Agent系统设计有直接影响：不能简单地用"最强模型"去填充每一个Agent节点。需要在Agent之间设计明确的承诺机制和声誉系统，才能让协作真正发生。
# 多Agent协作中的承诺机制示例
class AgentCoordinator:
def __init__(self):
self.reputation_scores = {} # agent_id -> score
self.commitment_log = [] # 已承诺任务的记录
def assign_task(self, task, agents):
# 优先分配给历史合作得分高的Agent
ranked = sorted(
agents,
key=lambda a: self.reputation_scores.get(a.id, 0.5),
reverse=True
)
selected = ranked[0]
# 记录承诺
commitment = {
"agent_id": selected.id,
"task_id": task.id,
"committed_at": time.time(),
"deadline": task.deadline
}
self.commitment_log.append(commitment)
return selected
def update_reputation(self, agent_id, success: bool):
current = self.reputation_scores.get(agent_id, 0.5)
# 指数移动平均
alpha = 0.2
self.reputation_scores[agent_id] = (
alpha * (1.0 if success else 0.0) + (1 - alpha) * current
)
四、工程师要怎么应对这场转变
说到这里，问题变得很具体了：作为工程师，该怎么看这件事？
- 先把Agent运营能力内化，不要等着别人来做
"智能体部署与管理者"这个岗位冒出来，本质上是因为现有的工程师和PM都没有覆盖这块能力真空。走得快的工程师会主动填补这个空白，而不是等一个新职位来接管。
具体来说，可以从这几件事开始练：
• 写每个Agent的"能力边界说明书"——它能做什么，不能做什么，在哪些条件下表现不稳定
• 在每个Agent上线时同步建一个最小可用的评估体系，哪怕只是一个简单的golden set
• 强制在设计阶段就考虑"人工兜底路径"——Agent失败时，人怎么接管？
- 技术判断力依然是核心，但要升维
吴恩达说"瓶颈从写代码转向产品决策"，不是说代码能力不重要了，而是说光有代码能力不够了。
工程师的优势是：能从架构层面理解为什么某种Agent设计在某类问题上会失效。这个判断力是PM和运营做不到的。
举个例子：当有人提议用一个超长上下文的单Agent来完成复杂任务时，工程师应该能立刻意识到——这在推理一致性上有风险，应该考虑任务分解+多Agent协作。这种判断，不是靠产品文档能学来的。
- 别把"让Agent自主运行"当成成功标准
这是最常见的认知误区。很多团队把"Agent能自主完成任务"当成终极目标，结果在追求自主性的过程中，忽略了可解释性、可控性和可审计性。
实际的生产系统需要的是：在正确的地方自主，在正确的地方停下来等人。
一个实用的设计原则：
# Agent的三段式自主性设计
class AgentAutonomyPolicy:
"""
ZONE 1 - 全自主：低风险、可逆操作，直接执行
ZONE 2 - 半自主：中等风险，执行后通知人类
ZONE 3 - 人工审核：高风险/不可逆操作，执行前请求确认
"""
def classify_action(self, action) -> str:
if action.risk_level == "low" and action.reversible:
return "ZONE_1_AUTO"
elif action.risk_level == "medium":
return "ZONE_2_NOTIFY"
else:
return "ZONE_3_REQUIRE_APPROVAL"
def execute(self, action):
zone = self.classify_action(action)
if zone == "ZONE_1_AUTO":
return self._execute_direct(action)
elif zone == "ZONE_2_NOTIFY":
result = self._execute_direct(action)
self._notify_human(action, result)
return result
else:
approval = self._request_human_approval(action)
if approval.granted:
return self._execute_direct(action)
else:
return self._handle_rejection(action, approval.reason)
五、OpenAI Sora的警示：多模态落地比想象中难
本周另一个值得关注的信号：OpenAI Sora团队负责人Bill Peebles离职，OpenAI已实质性调整了多模态视频生成的战略方向。
Sora在2024年2月发布演示时震撼了整个行业。但从演示到产品，中间有一道非常难跨越的鸿沟。
这道鸿沟不只是计算成本的问题（虽然成本确实极高），更深层的问题是：
• 视频生成的"可控性"极低，用户无法精确描述想要的结果
• 质量评估缺乏客观标准，不像文字或代码有清晰的对错
• 商业化路径不清晰——谁会为不可控的视频生成付钱？
这和Agent落地的困境是同一个模式：技术上有突破，但从"能用"到"好用"、从"好用"到"值钱用"，每一步都是陡坡。
Nathan Lambert在他新发布的《My bets on open models, mid-2026》里有一个判断我认同：开源模型在2026年下半年会在推理能力上基本追上GPT-4o水平，真正拉开差距的会是"谁能做好RLHF之后的产品化这最后一公里"。
Sora的困境和这个判断是一致的：技术突破很重要，但产品化能力正在成为新的分水岭。
六、一个可以立即行动的清单
如果你在做Agentic系统，或者打算做，这里有一个不需要等待组织变革就能立刻执行的清单：
Agent落地最小化检查清单
任务定义：写下Agent的能力边界，明确"不做什么"
评估体系：至少有20条Golden Set，上线第一天就跑基准
自主性策略：定义三个区域（全自主/通知/审核），高风险操作绝对不自主
人工兜底：有明确的escalation路径，人能在5分钟内接管
行为监控：记录每次执行的输入/输出/步骤，支持事后审计
漂移检测：模型升级后自动跑Golden Set对比，防止静默退化
这个清单没有一项需要等老板同意，也没有一项需要专门的新职位。它就是"有Agent运营意识的工程师"应该做的基本动作。
总结
Agentic AI的瓶颈换位了，从"能不能"变成了"如何在生产中活下去"。这不是技术退步，是成熟的标志。
会出现的一种分化是：一批工程师会把精力继续放在模型能力和框架创新上（这很有价值），另一批工程师会把技术能力和运营视角结合起来，成为真正能推动Agentic系统落地的人（这更难，也更稀缺）。
吴恩达说的那句话，如果用一个不那么客气的方式翻译，大概是这个意思：
"会写代码已经不够了。下一个问题是：你知道该让Agent做什么吗？"
这个问题，值得每个在做AI系统的工程师认真想一想。
下一步我想探索的方向：Agent的评估体系里，如何引入Conformal Prediction来给不确定性估计一个有统计保证的置信区间——毕竟，"我不知道"本身也是一种很有价值的输出。
