当我的Cursor学会了Function Calling

最近折腾Cursor的Function Calling能力，源于一个让我熬了两通宵的需求：为分布式任务调度系统做一个聊天机器人，让运营能通过自然语言查询任务状态。任务数据散落在Redis、MySQL和ES里，传统NLP方案写意图识别和实体抽取，准确率惨不忍睹——运营说话太随意，规则引擎堆成了屎山。

核心思路很清晰：让大模型理解自然语言，通过Function Calling将意图转换为具体API调用。在.cursorrules里定义函数签名，把核心接口抽象出来：

functions = [
    {
        "name": "query_task_status",
        "description": "查询指定任务在某个时间段内的执行状态",
        "parameters": {
            "type": "object",
            "properties": {
                "task_name": {"type": "string", "description": "任务名称，可能是中文描述或任务标识"},
                "time_range": {"type": "string", "description": "时间范围，如'昨天'、'最近一小时'"},
                "task_id": {"type": "string", "description": "任务的唯一标识ID"}
            }
        }
    },
    {
        "name": "get_task_logs",
        "description": "获取任务的详细执行日志",
        "parameters": {
            "type": "object",
            "properties": {
                "task_id": {"type": "string"},
                "log_level": {"type": "string", "enum": ["ERROR", "WARN", "INFO"]}
            }
        }
    }
]

Cursor的代码生成配合Function Calling效率极高，但踩了几个坑。一是函数调用循环：用户问“查查昨天所有失败的任务”，模型先调query_task_status拿到列表，又自动调get_task_logs获取详情，递归导致token消耗爆炸，一次查询花0.3美元。赶紧加上最大调用深度限制。

二是边界判断缺失：用户问“今天心情不好，任务都正常吗”，模型竟把“心情不好”当任务名查询。我在system prompt里加了严格约束，让模型不确定时先跟用户确认，而非瞎调用。

三是性能问题：ES查询慢导致函数调用超时。搞了异步机制，函数返回任务ID，后台查询完成后通过WebSocket推送结果。Cursor帮忙重构时连超时重试逻辑都写得很漂亮。

上线后效果出乎意料。运营查任务像聊天一样，“朕想知道昨天的数据怎么样了”都能正确理解。Function Calling的精髓在于把大模型从“只会说”变成“真能干”。Cursor的深度整合大幅提升开发效率，插件都卸了不少。

当然这不是银弹。函数定义必须清晰，参数描述要详细，否则模型容易理解偏差。成本控制也关键，我给每个用户设每分钟最多5次查询限制，配合缓存策略，平衡体验和预算。这套方案值得深入研究，尤其在Cursor这类工具降低门槛后，剩下的就是业务理解和架构能力了。