DoneHub
0%

AI Agent 工程师的核心能力

发表于 更新于 分类于 Valine：

前几天看到一个视频在技术群里被转发，讲 AI Agent 工程师的 4 个核心技能：编程功底、Prompt Engineering、系统思维、领域知识。评论区一堆人收藏说太对了。我不否认这个框架，但实际做了几个 Agent 项目上线之后，我发现真正卡脖子的能力，那视频压根没提。

编程功底

现在各种 Agent 平台吹得天花乱坠，拖拖拽拽就能搭一个 Agent。但当你真正要处理复杂场景的时候，就会发现平台给的抽象根本不够用。你得能自己写工具函数、处理异步并发、管理状态流转。Python 目前确实是主流，LangChain 和 LangGraph 绕不开，但我建议先搞懂核心概念再碰框架，不然很容易变成会调 API 但不理解底层运行机制的状态。

具体来说，几个基本功必须扎实。异步编程方面，Agent 的工具调用基本都是 I/O 密集型，async/await 不熟练的话性能会很难看。状态管理方面，多轮对话的上下文维护、存储介质选择、过期策略制定，这些问题都需要在动手之前想清楚。工具抽象方面，把任意一个 HTTP API 或 Python 函数包装成 Agent 可调用的 Tool，返回值格式化处理，这些都是日常开发中反复遇到的工作。

LangGraph 的 StateGraph 是个很好的学习切入点，它能逼着你思考 Agent 的每个节点是什么状态、边是什么条件、死循环了怎么退出。把这些基础问题想明白之后，再上手框架效率会高很多。

Prompt Engineering

很多人对 Prompt Engineering 的理解还停留在把问题写清楚一点。这没错，但太浅了。实战中的 Prompt 设计更像是在设计一套交互协议，你要规定输入格式、输出格式、错误时的行为，甚至要考虑模型不听话的时候怎么兜底。

结构化输出比自由发挥靠谱得多。能用 JSON Schema 约束输出的，就别让模型自由生成文本。函数调用（Function Calling）本质就是干这个的。Few-shot 也不是随便塞几个例子就行，例子的选择要有代表性，覆盖正常路径和边界情况。我见过最典型的翻车案例是 Few-shot 里全是成功调用的例子，结果线上 Agent 遇到异常参数直接瞎编返回值。

多轮对话的上下文设计是个独立的技术方向。你不能把全部历史都塞进去，context window 有限，而且越贵的模型 context 越长但也不是无限的。常见的做法是最近 N 轮保留原文，更早的对话做摘要压缩，关键信息如用户偏好和已确认的约束单独维护一个工作记忆。LangGraph 的 Memory 模块有现成实现，但搞清楚原理再直接用，出了问题才好排查。

系统思维

你设计的 Agent 在执行时，本质上是一个状态机在跑：收到输入，判断要不要调用工具，拿到工具结果，决定下一步。这个循环可能执行 1 次，也可能执行 10 次，取决于任务复杂度。

任务编排不是线性流程。有些步骤可以并行，比如同时查天气和查路线；有些必须串行，比如先查用户权限再查数据。LangGraph 的 DAG 编排能解决这个问题，但你要先能画得出这个图。

异常处理比正常流程重要 10 倍。Agent 会幻觉，工具会超时，API 会返回意料之外的数据。你设计的每一个节点都要有 fallback 方案：工具调用失败是重试还是跳过，模型返回格式不对能不能重试一次以及重试几次就放弃，Agent 陷入循环怎么检测和强制退出。

我曾经写过一个 Agent，让它根据用户描述自动生成 SQL 查询。正常情况没问题，但用户输入模糊的时候，Agent 会不断生成错误的 SQL，然后执行失败，然后重新生成，循环到 API 调用上限才停。后来加了个计数器，同一个用户意图最多重试 3 次，超过就直接返回提示让用户说具体一点。这个教训让我对异常处理的优先级有了完全不同的认识。

领域知识

光会技术不懂场景，做出来的东西只能 demo 不能上线。领域知识融合不是说你去学点业务知识就完了，而是要把业务知识变成 Agent 能理解和使用的东西。

具体做法有几个方向。RAG（检索增强生成）把行业文档、SOP、知识库向量化，Agent 决策前先检索相关上下文。规则引擎加 LLM 的组合方式适合有硬规则的场景，比如金额超过某个阈值必须走审批，这种别指望 LLM 能记住，用代码写死，只在需要灵活判断的地方交给模型。工具选择也要贴合场景，客服 Agent 需要的工具是查订单、查物流、查退换货政策，代码 Agent 需要的是代码搜索、lint、测试运行，工具集决定了 Agent 的能力边界。

可观测性

上面四个是那个视频也提到的基础能力。接下来四个，是我在实战中觉得真正拉开差距的地方。

传统程序出 bug 了，你打日志、看堆栈、断点调试。Agent 出问题了就不一样了，它的执行路径是动态的，同一输入每次走的路线可能都不一样。没有可观测性，Agent 就是个黑盒，你只能看到输入和输出，中间发生了什么全靠猜。

你需要知道 Agent 做了什么决策以及为什么选这个工具而不是那个，工具调用的输入输出分别是什么以及耗时多久，哪一步开始偏离了预期路径，用户不满意的结果是怎么一步步产生的。

LangSmith、LangFuse 这类工具可以帮你追踪 Agent 的执行链。但别完全依赖第三方，哪怕自己打日志，也要保证每个关键节点有 trace_id，能把一次完整的 Agent 执行链路串起来。

1
2
3
4
5
6
7
8
9
10
11
12
# 给每次 Agent 执行一个 trace_id
import uuid

def run_agent_with_trace(user_input):
    trace_id = str(uuid.uuid4())[:8]
    logger.info(f"[trace:{trace_id}] Agent start, input: {user_input[:50]}...")
    
    # 每个工具调用前后都打日志
    result = execute_tool_with_logging(tool_name, args, trace_id)
    
    logger.info(f"[trace:{trace_id}] Agent complete")
    return result

有了这个，用户投诉的时候你能直接查到那天那个 Agent 到底干了什么，而不是回一句我们再看看。

评估体系

传统代码好不好，跑个单元测试就知道。Agent 好不好，缺少一个客观的衡量标准。没有评估体系的 Agent 迭代就是瞎猜，你改了 Prompt 觉得效果更好了，但这个好是你觉得还是数据说的，需要一套能量化的机制来回答。

你需要关注的指标包括：工具调用的准确率（不该调的时候没调，该调的时候调对了），输出质量（格式正确率、事实准确性、用户满意度），以及不同 Prompt 版本之间哪个更好的对比数据。

落地路径可以分三步走。第一步建一个 Golden Dataset，收集 50-100 个典型的真实用户输入，标注期望的行为（该调什么工具、期望输出什么）。第二步每次改 Prompt 后跑一遍回归测试，看通过率有没有下降。第三步线上埋 A/B 测试，新 Prompt 灰度一部分流量，对比指标。不需要一开始就搞得多完善，先有几个核心用例能跑起来，后面再慢慢加。

成本意识

Agent 每次调用 LLM 都烧钱。一个复杂的多步 Agent，单次对话可能调用 10 次以上模型，成本随着调用次数往上叠加。

几个省钱的实战思路。大小模型搭配，不是所有判断都需要 GPT-4，意图分类、格式校验这种任务，用个小模型或者干脆用代码判断就行，只有真正需要推理能力的步骤才上大模型。缓存结果，同样的问题不应该反复问模型，比如用户问北京今天天气，同一天内第二次问直接返回缓存，别再调 API。Prompt 瘦身，检查一下你的 system prompt 有多少 token，里面有多少是每次都必须的，能压缩的就压缩，每次调用都在烧钱。限制最大步数，Agent 的最大循环次数设个上限（比如 10 步），超过就终止，不然一个搞不定的任务会一直烧钱直到超时。

我自己做过一个对比：一个 Agent 流程，优化前平均每次对话烧 $0.12，优化后降到 $0.03。不是模型换了，是调用次数少了、context 短了、不必要的步骤砍了。

边界控制

Agent 什么都答应，最后什么都做不好。好的 Agent 不是万能的，而是知道自己不能干什么。

工具权限边界方面，不是所有工具都应该对所有人开放。查公开信息可以，删数据不行。这个不能靠 Prompt 约束（模型可能不听话），必须在代码层面做权限校验。Prompt 注入防御方面，用户输入里如果藏着忽略之前指令的注入内容，你的 Agent 可能会中招，输入过滤和指令隔离是必须的安全措施。能力边界方面，Agent 遇到超出能力范围的问题，应该直接说这个问题我处理不了，而不是硬编一个答案。这需要你在系统层面做意图识别，不属于这个 Agent 管辖范围的问题，直接拒绝或者转人工。

能跑通 demo 和能上线生产，中间差了可观测性、评估体系、成本控制、安全边界。这些东西不性感，但决定了你的 Agent 能不能从玩具变成产品。真正让 Agent 工程师值钱的，不是让 AI 能工作，而是让它可靠地工作。

扫描二维码分享