一件你可能还没察觉的事

前几天有个工程师朋友跟我说了一句话，让我想了很久：

“我现在每天用 AI 写代码，但我已经很久没有完整地想过一个问题了。”

他不是在抱怨。他是有点茫然。

这种感觉很多人可能有：效率高了，但思维好像变浅了。用 Cursor 一下生成 200 行，Diff 看起来没问题，合进去。下一个任务。然后呢？如果哪天 AI 给了个看起来正确但实则有坑的答案，你还有没有能力识别出来？

这不是"AI 会不会替代工程师"的老问题。这是一个更具体的问题：在和 AI 协作的过程中，工程师的判断力会不会悄悄萎缩？

我的答案是：如果不主动对抗，会。

但还有另一面，同样真实：Agent 时代给工程师带来了一种过去不可能获得的能力——一个人，可以驾驭一支小团队量级的产出。这不是比喻，是现在正在发生的事。

这篇文章想聊的，就是这个时代里工程师在失去什么、在获得什么，以及怎么做选择。

范式迁移：从"推理"到"行动"，变化比你想的大

前阿里千问技术负责人林俊旸离职后第一次公开发声，用了"范式迁移"这个词。他的判断是：AI 正在从 Reasoning Thinking（推理思维） 进入 Agentic Thinking（智能体思维）。

这不只是技术词汇的切换，背后是完全不同的工作模式。

推理阶段（o1、R1 代表）的核心是：模型在回答之前多想几步，在可验证领域（数学、代码、逻辑）取得突破。这个阶段对工程师的要求主要是：写好 Prompt，选对模型，接好 API。门槛不低，但是相对清晰的技能树。

智能体阶段的核心变了：AI 不再只是"想答案"，而是"做事情"——调工具、与外部环境交互、根据反馈修正计划、跨多轮保持连贯。林俊旸的原话很到位：

“好的思维不再是产生最令人印象深刻的中间文字，而是能在现实约束下维持有效行动的最实用路径。”

一旦加入"行动"，复杂度就不是线性增加了。推理是在模型内部完成的，结果要么对要么错。但 Agent 的行动会改变外部状态，而外部状态又会反过来影响 Agent 的下一步决策——这是个闭环系统，失败的方式变得更多、更难预测。

Simon Willison 转发的一段话，我觉得把这个矛盾说得最清楚：

“给 Agent 一个问题和一个 while 循环，它最终会解决这个问题，哪怕烧掉一万亿 token 然后把代码重写到硅基层面。但工程师真正想要的是：快速解决、可维护、可适配、可复用。”

Agent 能"硬解"，工程师要的是"优雅地解"。这个差距，就是工程师现在最有价值的地方。

你在 Agent 系统里，扮演什么角色？

这个问题现在问，大多数人会说"我是用户"。但用户是会被工具取代的位置。

我认为工程师在 Agent 时代有三个有价值的角色：系统设计者、评估者、环境构建者。这三个角色越往后越难替代，也越稀缺。

先说评估者。这个词听起来简单，但其实是目前整个 AI 工程化链条里最薄弱的环节。

传统软件测试逻辑清晰：输入 → 预期输出 → 断言。Agent 打破了这个模型。Agent 的每一步都可能引发分叉，最终结果正确但路径错了，或者路径合理但结论偏了。而且 Agent 的"幻觉式正确"尤其危险——输出看起来合理，实际上调用了一个不存在的 API，或者凭空构造了一个假数据。

能设计好 Agent 评估体系的工程师，在团队里的地位相当于过去的 QA Lead，但技术含量远更高。有一个三层评估模型值得记住：

层次	评估什么	能回答的问题	类比
最终响应（黑盒）	最终输出对不对	What 出错了	知道答案错了但不知为何
轨迹评估（破壳）	执行路径是否合理	Where 断裂了	定位到决策链断裂点
单步评估（白盒）	每个工具调用是否正确	Why 每步决策对/错	单元测试，隔离验证

大多数团队目前停在黑盒阶段——跑 Demo，看结果，觉得好就上线。这是很脆弱的工程状态。真正有工程深度的做法，是给每个 Agent 任务建一个评估数据集，实现轨迹记录，让每次 Prompt 或模型变更都有量化的回归测试。

动手：一个真实可用的 Agent 轨迹评估器

说具体的。下面这个 Python 实现可以直接用，核心思路是：用 LCS（最长公共子序列）而不是精确匹配来比较实际工具调用序列和预期序列——因为 Agent 经常会"多走几步"，精确匹配会误杀很多合理行为。

from dataclasses import dataclass, field
from typing import List, Optional

@dataclass
class ToolCall:
    name: str
    args: dict = field(default_factory=dict)

@dataclass
class TrajectoryStep:
    thought: str
    tool_call: Optional[ToolCall] = None
    observation: str = ""

@dataclass
class EvalCase:
    id: str
    user_input: str
    expected_trajectory: List[str]       # 期望的工具调用名称序列
    expected_output_keywords: List[str]  # 输出应包含的关键词

def lcs_score(expected: List[str], actual: List[str]) -> float:
    """
    用 LCS 计算轨迹匹配率。
    不用精确匹配是因为 Agent 常插入合理的额外步骤，
    精确匹配会误判为失败。
    """
    m, n = len(expected), len(actual)
    if m == 0:
        return 1.0
    dp = [[0] * (n + 1) for _ in range(m + 1)]
    for i in range(1, m + 1):
        for j in range(1, n + 1):
            if expected[i-1] == actual[j-1]:
                dp[i][j] = dp[i-1][j-1] + 1
            else:
                dp[i][j] = max(dp[i-1][j], dp[i][j-1])
    return dp[m][n] / m

def keyword_coverage(keywords: List[str], output: str) -> float:
    if not keywords:
        return 1.0
    hits = sum(1 for k in keywords if k.lower() in output.lower())
    return hits / len(keywords)

def run_eval(agent_func, cases: List[EvalCase]):
    print(f"{'Case':6} {'Output':>7}  {'Status'}")
    print("-" * 55)
    for c in cases:
        steps, final_output = agent_func(c.user_input)
        actual_tools = [s.tool_call.name for s in steps if s.tool_call]
        t = lcs_score(c.expected_trajectory, actual_tools)
        o = keyword_coverage(c.expected_output_keywords, final_output)
        ok = "✅" if t >= 0.8 and o >= 0.8 else "❌"
        print(f"{c.id:5.0%}  {o:>6.0%}  {ok} {actual_tools}")

# ---- 使用示例 ----
cases = [
    EvalCase(
        id="search_summarize",
        user_input="查最新 LLM 评估方法并总结",
        expected_trajectory=["web_search", "summarize"],
        expected_output_keywords=["评估", "LLM"]
    ),
]

def mock_agent(user_input):
    steps = [
        TrajectoryStep("需要搜索", ToolCall("web_search", {"q": user_input}), "结果..."),
        TrajectoryStep("整理", ToolCall("summarize", {}), ""),
    ]
    return steps, "关于 LLM 评估方法的总结..."

run_eval(mock_agent, cases)

这段代码的实际作用：把它接入 CI/CD，每次改 Prompt、换模型或调整工具配置时自动跑一遍。如果轨迹分或关键词覆盖率下降超过阈值（比如 10%），拦截部署。这才是把 Agent 当工程产品对待，而不是 Demo。

Harness Engineering：一个正在形成的新工程方向

林俊旸在谈智能体时代的竞争优势时，用了"环境设计"这个词。同期 ArXiv 上也有一篇论文直接以"Natural-Language Agent Harnesses"为题，研究怎么把 Agent 的控制逻辑系统化——作者们发现，这块工作通常埋在 Controller 代码里，缺乏标准化，难以复用和比较。

“Harness”（马甲）这个词在 Agent 工程里指的是：围绕核心 AI 模型构建的运行时控制框架——工具服务器、沙箱、Orchestrator（协调器）、评估器这些基础设施的集合。

用一张简图来理解架构层次：

┌─────────────────────────────────────────────────┐
│                  Orchestrator                     │
│     (任务分解 → 路由 → 失败恢复 → 上下文管理)      │
└────────────────┬────────────────────────────────┘
                 │
     ┌───────────┼───────────┐
     ▼           ▼           ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Agent A │ │ Agent B │ │ Agent C │
│  搜索   │ │  代码   │ │  写作   │
└────┬────┘ └────┬────┘ └────┬────┘
     └───────────┼───────────┘
                 ▼
┌─────────────────────────────────┐
│         Tool Server Layer        │
│  统一接口 · 速率限制 · 错误隔离  │
└─────────────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────┐
│        Sandbox / Evaluator       │
│   轨迹记录 · 奖励计算 · 异常检测  │
└─────────────────────────────────┘

工程师能在这个架构里贡献的价值：Tool Server 的健壮性设计（统一错误格式、超时处理、幂等性保证），以及 Evaluator 的评估逻辑。这两块是目前 AI 工具链里最薄弱的环节，也是最接近传统软件工程能力的地方。

有一个容易被忽视的风险叫 Reward Hacking：当 Agent 有工具访问权限后，可能学会通过直接查答案或利用环境漏洞来"作弊"，而不是真正解决问题。这不是假设，是在实际 Agent 项目里真实发生过的。设计能防止这类问题的沙箱环境，是一个有相当技术含量的工程挑战。

一个被反复验证的规律：工具会过时，原理不会

Keras 之父 François Chollet 最近的动作值得关注。他离开 Google，创立新实验室 Indie，做的是"程序综合"路线——核心思路是：与其用数百亿参数去拟合数据，不如寻找能用最少信息量来描述数据规律的符号模型。他的预言是，AGI 的核心代码可能不足一万行，而且用 80 年代的计算机就能跑。

听起来很离谱。但他的底层逻辑很清晰：当前大模型是在用暴力计算弥补优雅理论的缺失。就像早期蒸汽机烧大量煤来实现内燃机用少量汽油就能做到的事。

对工程师的启示不是"去研究程序综合"，而是：不要把对特定工具或框架的熟练度当成护城河。

Cursor 会被更好的工具替代。LangChain 的 API 还在变。GPT-4o 会被下一代模型超越。但理解 Transformer 为什么会产生幻觉、理解 RL 奖励机制的本质、理解为什么某种 Prompt 结构更稳定——这些知识的半衰期长得多。

同期还有一篇值得关注的论文：S2D2，针对扩散语言模型（Diffusion LLM）的推理加速方案，通过自推测解码在极少步数下实现接近全步数的质量。这代表了一条和自回归完全不同的生成路线，目前还很早期，但技术路线的多样性本身就提示我们：能快速理解一个新方向、判断其应用价值的能力，比掌握当前最热工具更值钱。

给工程师的具体建议：不是"学更多"，是"学对的"

现在关于 AI 的学习资源多到溺水。但方向不对，学再多也是在跑步机上。

我认为当前阶段最值得投入的三件事：

① 建立对 AI 能力边界的真实直觉

不是读论文，是动手触发失败。认真做一个 Agent 项目，亲手遇到幻觉、工具循环、上下文窗口超限、Reward Hacking 这些问题，比看十篇教程有用。知道 AI 在哪里容易出错，比知道它能做什么更重要。

② 给你接入的 AI 系统建评估基准

哪怕只是 10 个测试用例。把期望的工具调用轨迹写下来，把期望输出的关键信息写下来。每次改动后跑一遍，看分数变没变。没有评估，你就是在盲飞。

③ 认真理解一个系统，而不是浅尝很多工具

选一个 Agent 框架，把它的源码读懂（不需要全读，读核心 20%）。理解它怎么做工具调用、怎么管理上下文、怎么处理错误。这个过程会给你一个"透视"AI 系统的能力，之后换别的框架也能快速上手。

最后，那个让人不安的问题

回到开头那个工程师朋友的问题——他开始"很久没有完整地想过一个问题了"。

这是一个真实的风险。当 AI 把大部分"想"的工作接管了，工程师的深度思考能力可能会在不知不觉中退化。就像导航 APP 普及之后，很多人的路感消失了一样。

但也有另一种可能：如果你主动把省出来的认知资源用在更高层次的判断上——架构取舍、系统边界设计、Agent 行为评估——那你不是退化，而是在进化。

这里有一个我认为 Agent 时代最核心的工程师能力，但几乎没人提：为 AI 的决策负责的意愿和能力。不是"AI 建议了，我接受了"，而是"我审查了 AI 的判断，我认同，我为这个结论背书"。

Agent 能越来越强，但"负责"这件事还没有被 AI 替代的迹象。负责意味着你理解决策的后果，能在出错时找到原因，能向别人解释为什么这样做。这恰好需要所有 AI 暂时还不具备的东西：context、judgment、accountability。

下一步值得探索的方向：Agent 的可审计性工程——如何让 Agent 的决策链对业务方透明、可追溯、可还原。不是研究层的机制可解释性，而是工程层的：当 Agent 出了问题，能不能在 5 分钟内定位到是哪一步、哪个工具调用、哪条 Prompt 路径导致的。这个方向目前几乎没有系统性实践，但随着 Agent 在生产环境渗透加深，需求会很快爆发。

如果你在 Agent 评估、Harness 工程或可审计性方面有实践心得，欢迎交流。