边备婚边折腾AI Agent框架，我踩过的坑都在这了
上周六下午，我正穿着婚纱在店里试第三套敬酒服，手机突然震了一下——组里的前端小哥在群里@我，说线上那个自动化工单分配系统又炸了。我一边提着裙摆一边掏出手机看日志，好家伙，又是大模型返回格式不对导致下游解析全崩。那一刻我真的想当场把婚纱退了回去写代码。
没错，我就是那个白天在公司写CRUD、晚上回家刷LeetCode、周末还要去试婚纱的备婚程序媛。最近半年简直是人生最魔幻的阶段：一边准备跳槽，每天中午偷偷刷两道算法题；一边还要跟进组里几个新项目的技术预研；另一边，婚期越来越近，各种琐事能把人逼疯。但没办法，谁让我是个闲不住的人呢，看到新技术就手痒。
今天这篇文章，就是想聊聊我最近在做技术预研时折腾的几个AI相关的东西——CrewAI、JetBrains Junie，还有Function Calling。说实话，一开始领导让我调研Agent框架的时候，我是拒绝的。心想我连婚期都搞不定了，还搞什么Agent？但后来发现这些东西确实能解决我们团队的一些痛点，而且对面试也有帮助（毕竟现在大模型方向太火了），就硬着头皮上了。结果一入坑深似海，踩了不少坑，也收获了一些心得，今天就来跟大家唠唠。
事情是这样的：我们为什么需要Agent
先说说背景。我们组做的是内部效能工具，说白了就是给公司其他研发团队做各种提效平台。去年底领导拍脑袋说要搞一个"智能运维助手"，需求大概是这样的：
- 用户用自然语言描述问题，比如"线上订单服务RT飙升，帮我看看怎么回事"
- 系统自动调用各种监控API、日志系统、变更记录
- 综合分析后给出排查建议，甚至自动执行一些修复操作
听起来很美好对吧？但真正落地的时候，问题就来了。
最开始我们用的是最朴素的方案——写一个大Prompt，把所有工具的说明塞进去，让大模型自己决定调哪个。结果可想而知，模型经常幻觉，明明该查日志它去查变更记录，返回的JSON格式也是随心所欲，有时候多个逗号有时候少个括号，下游解析直接报错。
后来我又试了LangChain，说实话那段时间LangChain的文档更新速度比我改婚纱尺寸还快，今天写的代码明天就deprecated了。而且它的抽象层太多了，一个简单的工具调用要绕好几个弯，调试起来简直想死。
就在这个时候，我发现了CrewAI。
CrewAI：多Agent协作的优雅解法
第一次看到CrewAI的时候，我眼前一亮。它的设计理念很戳我——把复杂的任务拆解成多个Agent，每个Agent有自己的角色、目标和工具，然后让它们协作完成任务。这不就是我们公司开会的模式嘛！产品经理提需求、开发评估方案、测试验收结果，每个角色各司其职。
举个我们实际的例子。在智能运维助手的场景里，我设计了这么几个Agent：
from crewai import Agent, Task, Crew, Process
# 监控数据分析Agent
monitor_agent = Agent(
role="监控数据分析专家",
goal="分析系统监控指标，找出异常点",
backstory="""你是一位资深的SRE工程师，
擅长从Prometheus、Grafana等监控系统中发现问题。
你对各种性能指标非常敏感，能快速定位瓶颈。""",
tools=[query_prometheus, query_grafana],
verbose=True,
allow_delegation=False
)
# 日志分析Agent
log_agent = Agent(
role="日志分析专家",
goal="从海量日志中提取关键错误信息",
backstory="""你是一位经验丰富的后端开发，
对Java异常堆栈、Go panic日志了如指掌。
你擅长从日志中发现问题的根因。""",
tools=[query_elasticsearch, query_kibana],
verbose=True,
allow_delegation=False
)
# 综合分析Agent
analysis_agent = Agent(
role="综合分析专家",
goal="综合各方信息，给出最终的排查结论和建议",
backstory="""你是一位技术总监，
擅长综合多个维度的信息做出准确判断。
你的建议总是切中要害，可操作性强。""",
tools=[],
verbose=True,
allow_delegation=True
)
# 定义任务
monitor_task = Task(
description="分析{service_name}服务最近1小时的监控指标，找出异常",
expected_output="包含关键指标变化、异常时间点的分析报告",
agent=monitor_agent
)
log_task = Task(
description="查看{service_name}服务最近1小时的错误日志，提取关键异常",
expected_output="包含错误类型、频率、典型堆栈的日志分析报告",
agent=log_agent
)
analysis_task = Task(
description="""综合监控数据和日志分析结果，
给出问题根因判断和修复建议""",
expected_output="结构化的问题诊断报告，包含根因、影响范围、修复建议",
agent=analysis_agent,
context=[monitor_task, log_task]
)
# 组建团队
crew = Crew(
agents=[monitor_agent, log_agent, analysis_agent],
tasks=[monitor_task, log_task, analysis_task],
process=Process.sequential,
verbose=True
)
# 执行
result = crew.kickoff(inputs={"service_name": "order-service"})
这套方案上线后效果还不错。最直观的感受是，每个Agent专注自己的领域，输出质量比之前一个大Prompt搞定所有事情要高很多。而且因为每个Agent的Prompt比较聚焦，幻觉也少了不少。
但是！CrewAI也不是完美的，踩坑记录来了：
坑一：Agent之间的上下文传递
一开始我把allow_delegation全设成True，想着让Agent们自由交流。结果有一次，监控Agent把一堆原始数据直接丢给分析Agent，分析Agent的上下文窗口直接爆了，返回了一堆乱码。后来我学乖了，给每个Task都加了expected_output，让Agent按照格式输出，上下文传递才稳定下来。
坑二：工具调用的稳定性
CrewAI底层还是依赖大模型的Function Calling能力。有时候模型会"创造性"地组合参数，比如把时间戳传成字符串，或者把数组传成逗号分隔的字符串。这个问题我后面会详细说。
坑三：调试体验
虽然CrewAI有verbose模式，但日志太多了，每次执行完控制台输出几千行，找关键信息跟大海捞针一样。后来我自己写了个回调函数，只记录每个Agent的最终输出和工具调用结果，清爽多了。
Function Calling：让大模型乖乖听话的关键
说到Function Calling，这真的是我最近花时间研究最多的部分。为什么？因为我们团队要跳槽面试的人不止我一个（没错，我们组最近离职率有点高，大家都懂的），好几个同事面试都被问到这块，我也就顺便深入学了一下。
Function Calling本质上就是让大模型按照我们定义的函数签名来返回结构化的调用参数。听起来很简单，但里面的门道可不少。
先说我们遇到的核心问题：怎么保证大模型返回的参数是合法的？
比如我们有一个查询监控数据的工具：
def query_prometheus(
metric_name: str,
time_range: str,
step: str = "60s",
labels: Optional[Dict[str, str]] = None
) -> Dict:
"""查询Prometheus指标数据"""
pass
理想情况下，大模型应该返回：
{
"metric_name": "http_request_duration_seconds",
"time_range": "1h",
"step": "60s",
"labels": {"service": "order-service"}
}
但实际使用中，大模型可能返回：
{
"metric_name": "http_request_duration_seconds",
"time_range": "过去一小时", // 不是合法的时间范围格式
"step": 60, // 应该是字符串
"labels": "service=order-service" // 应该是字典
}
这时候如果你直接拿这些参数去调API，必崩无疑。
我尝试了几种方案，总结一下各自的优缺点：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 纯Prompt约束 | 简单直接 | 不稳定，模型经常不遵守 | 对格式要求不高的场景 |
| JSON Schema + 重试 | 有校验机制 | 重试增加延迟和成本 | 大多数业务场景 |
| Instructor/Outlines | 强类型保证 | 需要额外依赖，部分模型不支持 | 对格式要求严格的场景 |
| 代码层兜底解析 | 容错性强 | 需要写大量兼容代码 | 历史遗留系统对接 |
最后我们采用的方案是 JSON Schema + 代码层兜底 的组合拳。核心思路是：
import json
from jsonschema import validate, ValidationError
from typing import Any, Callable
import functools
def strict_tool_call(tool_func: Callable) -> Callable:
"""工具调用装饰器，确保参数合法性"""
@functools.wraps(tool_func)
def wrapper(raw_params: str) -> Any:
try:
# 第一步：尝试直接解析
params = json.loads(raw_params)
except json.JSONDecodeError:
# 第二步：尝试修复常见的JSON格式问题
params = try_fix_json(raw_params)
# 第三步：参数类型转换和校验
params = normalize_params(params, tool_func)
# 第四步：JSON Schema校验
schema = get_tool_schema(tool_func)
try:
validate(instance=params, schema=schema)
except ValidationError as e:
# 记录日志，尝试用默认值填充
params = fill_defaults(params, schema)
return tool_func(**params)
return wrapper
def try_fix_json(raw: str) -> dict:
"""修复常见的JSON格式问题"""
# 处理单引号
raw = raw.replace("'", '"')
# 处理尾部逗号
raw = re.sub(r',\s*}', '}', raw)
raw = re.sub(r',\s*]', ']', raw)
# 处理没有引号的key
raw = re.sub(r'(\w+)\s*:', r'"\1":', raw)
try:
return json.loads(raw)
except:
# 最后的兜底：用正则提取关键信息
return extract_key_info(raw)
这套方案上线后，工具调用的成功率从78%提升到了96%。剩下的4%主要是一些特别复杂的嵌套结构，模型实在搞不定，这种情况我们就降级到人工处理了。
另外一个心得是，给大模型写工具描述（tool description）非常重要。一开始我们的工具描述写得特别简略，就一行"""查询数据"""，结果模型经常瞎调。后来我参考OpenAI的最佳实践，把每个工具的描述都写详细了，包括参数含义、取值范围、示例等，效果立竿见影。
# 改造前
def query_prometheus(metric_name: str, time_range: str):
"""查询数据"""
pass
# 改造后
def query_prometheus(
metric_name: str,
time_range: str,
step: str = "60s"
) -> Dict:
"""
查询Prometheus监控指标数据。
Args:
metric_name: 指标名称，必须是Prometheus中已注册的指标。
常用指标包括：
- http_request_duration_seconds: HTTP请求延迟
- http_requests_total: HTTP请求总数
- process_cpu_seconds_total: CPU使用量
time_range: 查询时间范围，格式为数字+单位。
支持的单位：s(秒), m(分钟), h(小时), d(天)
示例：'30m', '1h', '7d'
注意：不要使用中文如'过去一小时'
step: 数据采样间隔，默认60s。
时间范围越大，step应该适当调大以避免数据量过多。
Returns:
包含时间序列数据的字典，格式为：
{
"status": "success",
"data": {
"resultType": "matrix",
"result": [...]
}
}
"""
pass
你看，就这么一个简单的改动，模型调用的准确率提升了将近20%。所以说，跟大模型打交道，Prompt工程真的是基本功，偷不了懒。
JetBrains Junie：IDE里的AI新玩法
说完了Agent框架和Function Calling，再聊聊最近让我比较兴奋的一个东西——JetBrains Junie。
先声明一下，我是JetBrains全家桶的重度用户，IDEA用了快十年了，PyCharm也是日常主力。所以当JetBrains宣布要做自己的AI Agent的时候，我第一时间就申请了内测。
Junie的定位跟一般的代码补全工具不太一样，它更像是一个能理解你整个项目的AI助手。它可以分析你的代码库结构、理解项目依赖关系，然后帮你完成一些比较复杂的任务，比如"给这个模块加上单元测试"、"把这个类重构成策略模式"之类的。
我实际体验下来，有几个点让我印象深刻：
1. 项目理解能力确实强
有一次我让它帮我分析一个老模块的依赖关系，这模块是三年前离职的同事写的，文档几乎没有。Junie不仅画出了依赖图，还指出了几个潜在的循环依赖问题。我当时就惊了，这要是让我自己看，至少得花半天。
2. 代码修改比较靠谱
跟Copilot那种逐行补全不同，Junie做的是"任务级"的代码修改。比如我说"给UserService加上缓存"，它会分析UserService的代码结构，找到合适的切入点，然后生成完整的修改方案。虽然不能直接copy paste，但作为参考已经非常好了。
3. 跟IDE深度集成
这点是Junie最大的优势。因为它就在IDE里面，所以它可以感知你的光标位置、选中的代码、打开的文件等上下文信息。你不需要像在其他AI工具里那样，手动把代码复制粘贴过去。
不过Junie目前也有一些不足：
- 对中文注释的理解还有待提高，有时候会忽略中文注释里的关键信息
- 大项目上响应速度偏慢，我们那个几百万行的 monorepo 跑起来有点吃力
- 目前只支持JetBrains系的IDE，VS Code用户暂时用不了（不过我主力就是IDEA，所以无所谓）
我现在的日常使用场景主要是：
- 写单测：选中一个类，让Junie生成测试用例，然后我在此基础上修改。比从零开始写快多了。
- 代码审查：提交PR之前让Junie过一遍，它能发现一些潜在的问题，比如空指针风险、资源未释放等。
- 重构辅助：做一些大规模重构的时候，让Junie先分析影响范围，然后再动手。
说实话，Junie目前还不能完全替代人工，但作为一个辅助工具，已经能帮我省下不少时间了。特别是在我这种"白天工作、晚上刷题、周末备婚"的高压状态下，能省一点时间都是救命的。
一些踩坑后的思考
折腾了这么多，分享几点我个人的思考，不一定对，权当抛砖引玉。
关于技术选型
选Agent框架的时候，不要盲目追新。CrewAI虽然好用，但它对大模型的Function Calling能力依赖很重。如果你的业务场景对工具调用的准确性要求极高，可能还需要在Function Calling层面做大量的工程化工作。我们团队最后的选择是CrewAI做上层编排，Function Calling层面自己做了一层封装和兜底。
关于大模型的能力边界
不要指望大模型能搞定一切。在实际业务中，大模型更适合作为"决策层"和"编排层"，具体的执行还是要靠传统的代码逻辑。我们有一个教训：最开始想让大模型直接生成SQL查询数据库，结果出了好几次数据事故（虽然都是测试环境），后来改成了大模型生成查询意图，由代码层翻译成SQL执行，才稳定下来。
关于工程化
AI应用落地的最大挑战不是模型能力，而是工程化。怎么保证稳定性？怎么做降级？怎么做监控？怎么处理大模型的延迟？这些问题不解决，Demo再酷炫也上不了生产。我们现在的做法是，每个Agent调用都加了超时控制和重试机制，关键路径上还做了人工确认的兜底。
关于学习节奏
最后说说学习这块。我最近学这些东西，其实挺碎片化的——早上通勤听播客、午休看文档、晚上回家写demo。效率说实话不高，但胜在持续。我的建议是，不要试图一口气学完，给自己定个小目标，比如"这周搞懂Function Calling的机制"、"下周用CrewAI跑通一个demo"，一点一点来。
写在最后
好了，啰嗦了这么多，该收尾了。
其实写这篇文章的时候，我的婚礼倒计时只剩不到两个月了。婚纱还没最终定下来，请柬还没发，酒店座位表还没排……想想就头大。但奇怪的是，写技术文章反而让我有一种放松的感觉。可能因为代码的世界是非黑即白的，bug就是bug，feature就是feature，不像备婚这件事，有太多的灰色地带和妥协。
说回来，CrewAI、Function Calling、JetBrains Junie，这几个东西我还在持续探索中。CrewAI我们已经在内部一个小范围上线了，反馈还行；Function Calling的工程化方案还在迭代；Junie是我个人的效率工具，用得越来越顺手。
如果你也在关注AI Agent方向，或者正在准备相关的面试，希望这篇文章能给你一些参考。有什么问题欢迎在评论区交流，我虽然忙，但看到还是会回的。
最后，祝所有在工作和生活中两头忙的打工人，都能找到属于自己的节奏。不说了，我要去试第四套婚纱了，我妈催我了。
P.S. 如果你也是备婚中的程序员，欢迎私信交流经验。特别是怎么在婚礼前赶完项目deadline这件事，我真的需要过来人的指导。
评论 0