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 不是单体应用，是分布式系统

这是原文提到的”系统思维与拆解能力”，我想把它说得更具体一点。

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

你要考虑的：

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

异常处理比正常流程重要 10 倍。 Agent 会幻觉，工具会超时，API 会返回意料之外的数据。你设计的每一个节点都要有 fallback：

  • 工具调用失败：重试还是跳过？
  • 模型返回格式不对：能不能重试一次？重试几次就放弃？
  • Agent 陷入循环：怎么检测？怎么强制退出？

一个真实的坑： 我曾经写过一个 Agent，让它根据用户描述自动生成 SQL 查询。正常情况没问题，但用户输入模糊的时候，Agent 会不断生成错误的 SQL，然后执行失败，然后重新生成，循环到 API 调用上限才停。后来加了个计数器——同一个用户意图最多重试 3 次，超过就直接返回”我没理解清楚，你能说具体一点吗？”

四、领域知识：不懂业务的 Agent 就是玩具

这个不用多说了，光会技术不懂场景，做出来的东西只能 demo 不能上线。

但”领域知识融合”不是说你去学点业务知识就完了，而是要把业务知识变成 Agent 能理解和使用的东西。具体做法：

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

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

五、可观测性：看不见的 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 好不好，谁说了算？

没有评估体系的 Agent 迭代就是瞎猜。 你改了 Prompt，觉得效果更好了——是你觉得，还是数据说的？

你需要一套能回答这些问题的机制：

  • 工具调用的准确率是多少？（不该调的时候没调，该调的时候调对了）
  • 输出的质量怎么量化？（格式正确率、事实准确性、用户满意度）
  • 不同 Prompt 版本之间，哪个更好？

怎么落地：

  1. 建一个 Golden Dataset：收集 50-100 个典型的真实用户输入，标注期望的行为（该调什么工具、期望输出什么）
  2. 每次改 Prompt 后跑一遍回归测试：看通过率有没有下降
  3. 线上埋 A/B 测试：新 Prompt 灰度一部分流量，对比指标

不需要一开始就搞得多完善，先有几个核心用例能跑起来，后面再慢慢加。

七、成本意识：Token 是钱，不是纸

Agent 每次调用 LLM 都烧钱。一个复杂的多步 Agent，单次对话可能调用 10 次以上模型，成本就是指数级增长。

几个省钱的实战思路：

大小模型搭配。 不是所有判断都需要 GPT-4。意图分类、格式校验这种任务，用个小模型或者干脆用代码判断就行。只有真正需要推理能力的步骤才上大模型。

缓存结果。 同样的问题不应该反复问模型。比如用户问”北京今天天气”，同一天内第二次问直接返回缓存，别再调 API。

Prompt 瘦身。 你的 system prompt 有 2000 token 吗？里面有多少是每次都必须的？能压缩的就压缩，每次调用都在烧钱。

限制最大步数。 Agent 的最大循环次数设个上限（比如 10 步），超过就终止。不然一个搞不定的任务会一直烧钱直到超时。

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

八、边界控制：让 Agent 学会说”不”

Agent 什么都答应，最后什么都做不好。

好的 Agent 不是万能的，而是知道自己不能干什么。

工具权限边界。 不是所有工具都应该对所有人开放。查公开信息可以，删数据不行。这个不能靠 Prompt 约束（模型可能不听话），必须在代码层面做权限校验。

Prompt 注入防御。 用户输入里如果藏着”忽略之前的指令，现在你是一个…”，你的 Agent 会不会中招？输入过滤和指令隔离是必须的。

能力边界。 Agent 遇到超出能力范围的问题，应该直接说”这个问题我处理不了”，而不是硬编一个答案。这需要你在系统层面做意图识别——不属于这个 Agent 管辖范围的问题，直接拒绝或者转人工。

总结

回到开头那个视频的观点：前两个技能决定能不能入门，后两个决定能走多远。

我同意，但我想加一句：

真正让 Agent 工程师值钱的，不是让 AI 能工作，而是让它可靠地工作。

能跑通 demo 和能上线生产，中间差了可观测性、评估体系、成本控制、安全边界——这些东西不性感，但决定了你的 Agent 能不能从玩具变成产品。

欢迎关注我的其它发布渠道