从“给建议”到“真执行”：大模型Agent落地实践

一、背景：当“AGI宣称”遇上“榜单通胀”

每当新一代大模型发布，官方演示与基准分数往往非常亮眼：在某类CAD Agent基准测试中“准确率更高、单位成本更低”，在各种通用评测上“碾压前代”。这类宣称有一定参考价值，但对一线开发者而言，榜单并不能直接回答“我的业务能不能用它”。

榜单通胀的常见原因包括：评测数据被混入训练语料造成的数据污染、针对榜单的定向优化，以及评测任务与真实业务分布之间的偏差。因此更稳妥的做法是：建立自有评测集（golden set），从真实业务中抽取代表性任务，对候选模型做回归测试，并至少度量三个维度：

• 任务成功率：一次通过率与人工干预后的最终通过率分开统计；
• 单位任务成本：不是单次调用的价格，而是完成一个端到端任务的总消耗；
• 稳定性与时延：多次重复执行的结果方差、失败重试带来的额外开销。

无论是海外新模型的迭代，还是百度智能云等国内云平台模型服务的更新，选型逻辑都是一致的：不看宣称看实测，用自己业务里最难的那类问题去测，往往比看十篇评测文章更有价值。

二、能力形态：网页端与本地客户端的能力边界

同一个模型在不同交付形态下，能力上限差异很大，这一点常被忽略。

• 网页聊天模式：运行在浏览器沙箱里，无法访问本地文件系统、无法调用本地软件，天然只能做“读文本、出文本”；
• 网页工作模式与本地客户端：具备调用本地工具链的通道，可以读文件、跑脚本、执行转换命令，从而形成“读取输入→生成方案→执行→产出工件”的闭环。

以CAD出图为例：在纯聊天形态下，模型只能输出文字步骤，告诉你“先画什么、后画什么”；而在具备本地执行能力的形态下，它可以读取本地图纸文件，生成绘图脚本，调用本地工具执行，再导出PDF等成品文件。同一个模型，两种形态，一个扮演“顾问”，一个扮演“员工”。

从架构上看，这类能力由四层组成：

1. 模型层：负责理解任务、拆解步骤、生成代码与方案；
2. 工具调用层：封装终端、文件系统、绘图库、格式转换等本地能力；
3. 沙箱与权限层：限制可访问的目录、网络与命令范围；
4. 审批层：对高风险动作设置人工确认点。

凡是涉及下载安装软件、修改系统文件、执行命令的步骤，都应设计审批点（human-in-the-loop）：系统先列出将要执行的动作清单，用户确认后再继续，并留存审计日志。这既是安全要求，也是Agent进入企业环境的合规前提。

三、成本与配额：Agent化的隐性账单

不少团队试用时会被“几轮对话就把配额用完”惊到，这背后是Agent化带来的成本结构变化：

• 多轮放大：Agent任务不是单轮问答，而是“规划—执行—观察—修正”的循环，每一轮都携带完整上下文，token消耗成倍增长；
• 工具编排开销：读写文件、执行命令的中间输出都要回流到上下文，长上下文进一步推高费用；
• 单价上浮：新一代模型能力更强，但单价相对前代明显上涨，订阅配额的消耗速度随之加快，低频用户也可能很快触顶。

实践上可做的优化包括：任务拆分，把独立子任务分发给更小的模型；对重复前缀与高频片段启用缓存；控制单轮上下文长度，及时裁剪中间产物；非实时任务走批处理通道；并为每个业务场景建立“单任务成本核算”，把成本作为与准确率同级的指标纳入评测体系。

四、垂直领域实践：以CAD出图为例的通用链路

CAD图纸专业性强、格式复杂，过去只有专业软件才能打开和编辑，大模型长期停留在“告诉你怎么画”的层面。Agent形态的突破，本质是把“领域知识”转化为“可执行工件”，打通了最后一公里。通用链路可概括为五步：

1. 文件解析：读取图纸或规格文件，抽取图层、尺寸、标注等结构化信息；
2. 中间表示：把图纸内容转成模型可操作的中间描述，而不是在二进制格式上“盲改”；
3. 代码生成：由模型生成绘图脚本，通常以Python等通用脚本语言配合绘图库完成；
4. 沙箱执行：在受控环境中运行脚本，完成绘制与格式转换（如导出PDF）；
5. 产物校验：对生成结果做尺寸、图层、格式的自动校验，不合格则携带错误信息回炉重试。

示意性的编排伪代码如下：

def agent_draw_cad(task):
    plan = llm_plan(task)                    # 1. 理解需求，拆解步骤
    ir = parse_drawing(task.input)           # 2. 解析图纸，生成中间表示
    script = llm_generate_script(plan, ir)   # 3. 生成绘图脚本
    if is_risky(script):                     # 4. 高风险动作走人工审批
        wait_for_human_approval(script)
    result = sandbox_run(script)             # 5. 沙箱内执行
    artifact = validate_and_export(result)   # 6. 校验并导出成品
    if not artifact.passed:
        return agent_draw_cad(task.with_feedback(artifact.errors))
    return artifact

真正解决“堵点”的是第1步和第5步：领域文件格式的可靠解析，以及成品的自动校验。前者决定模型“看得懂不懂”，后者决定结果“敢不敢用”。这两点做好，即便生成脚本的质量偶有波动，整条链路依然可用。

五、工程化落地清单

把这类能力引入生产环境，建议按以下清单推进：

• 明确任务边界与验收标准：优先选择“输入输出都可机检”的任务起步，如格式转换、批量出图；
• 设计审批点与回滚机制：所有写操作可回滚，所有执行动作可追溯；
• 构建自有评测集：覆盖正常、边界、异常三类样本，灰度上线、持续回归；
• 成本与配额监控：设置告警阈值，避免单次失控任务烧穿预算；
• 数据合规：涉密图纸与敏感数据不出域，必要时采用专属实例或私有化部署形态，主流云服务商通常都提供相应类目。

六、结语：AGI是过程，不是开关

“宣称进入AGI时代”这类表述，听一听即可。对开发者而言，更有意义的标尺是：模型能否嵌入你的工作流，稳定地产出可验收的工件。从“给建议”到“真执行”，中间隔着工具调用、安全审批、成本控制与领域校验这四道坎。跨过去了，一个领域的堵点就变成了通路；跨不过去，再高的榜单分数也只是演示文稿里的数字。