通用智能体宣称AGI后如何做工程化评测

面对一款宣称具备通用人工智能（AGI）能力的新模型，最稳妥的态度不是立刻相信或否定，而是把它放回工程实践中检验：它能否在真实环境中完成端到端任务，能否交付可打开、可验证、可复用的产物，能否在成本、安全与可靠性约束下稳定运行。原始讨论中提到的现象很有代表性：模型在基准任务上评分很高，甚至宣称单位成本更低；但真正进入本地环境、专业软件、动态页面和复杂报告场景后，评价标准会迅速从“回答得像不像”转为“任务能不能闭环”。因此，看待此类能力宣称，应坚持一个原则：基准分数是入口，不是结论；任务闭环和单位成功成本才是关键指标。

一、先厘清“AGI宣称”的评测边界

AGI不是一个可以用单一榜单证明的状态。工程上更可操作的拆解是：跨领域迁移能力、工具调用能力、长程规划能力、环境交互能力、结果校验能力、异常恢复能力以及安全边界控制能力。一个模型能在文本问答中给出高质量答案，并不等于它能稳定操作本地环境；能在演示视频中完成一次任务，也不等于它能在不同输入、不同权限、不同数据条件下复现。

因此，评测设计应从“单轮问答”升级为“任务闭环”。所谓闭环，至少包括：理解任务、拆解步骤、选择工具、执行操作、检查中间结果、处理异常、生成最终产物、记录审计信息。对于专业任务，还应增加人工审批节点和产物校验节点。只有把“会建议”与“会交付”分开评估，才能判断其能力边界。

二、环境与权限：本地执行、服务端调用与审批门禁

很多能力在网页聊天模式中受限，原因并不复杂：网页环境通常无法直接操作本地文件、安装软件或访问本地计算资源；而桌面客户端或工作模式往往通过服务端接口调用模型能力，能够借助本地代理完成部分操作。两者并非简单的前端差异，而是权限模型、执行位置和工具链能力的差异。

在评测时，应明确三个问题：第一，任务在哪个环境执行，是纯对话、网页工作区、桌面代理还是受控沙箱；第二，模型能调用哪些工具，是只读检索、文件写入、软件安装、外部上传还是本地命令执行；第三，哪些步骤需要人工审批。原文提到涉及操作电脑和下载软件的步骤都需要人工审批，这正是工程上应坚持的安全门禁。审批不是能力缺陷，而是风险控制：本地写入、软件安装、外部上传、敏感数据读取都应有明确的授权边界。

示意性伪代码如下：

task = {
  type: "professional_delivery",
  inputs: { source, constraints },
  tools: ["domain_tool", "file_tool", "validator"],
  approvals: ["local_write", "software_install", "external_upload"]
}
plan = agent.plan(task)
results = []
for step in plan.steps:
    if step.needs_approval in task.approvals:
        wait_for_human_approval(step)
    result = sandbox.execute(step.tool, step.args)
    assert validator.check(result)
    results.append(result)
record_audit(plan, results, cost)

这段伪代码强调三件事：沙箱执行、审批门禁和审计记录。没有这三者，智能体越“能干”，风险越大。

三、专业CAD任务：从“告诉你怎么画”到“交付可打开文件”

CAD类任务是检验智能体工程能力的良好样本。传统问答模型往往只能告诉用户“如何画”：先建图层、再画轮廓、标注尺寸、检查约束。但这只是知识建议，不是交付结果。真正的CAD任务需要模型理解图纸结构、调用领域工具、生成或修改图形文件、处理格式转换，并对最终文件进行可打开性和几何一致性校验。

评测时应关注：模型能否正确理解输入图纸与约束；能否在工具链中执行而不是只在文本中描述；能否处理图层、尺寸、标注、单位等细节；能否进行格式转换并保持可读；能否发现自身错误并重试；最终产物能否被人工复核。原文提到从“告诉怎么画”到“自己调用脚本与CAD工具，把CAD真正画出来”，这正体现了从知识建议到工具执行的跨越。该跨越的价值不在于演示炫技，而在于解决专业领域的堵点：减少重复操作、降低格式转换成本、把人工从机械步骤中释放出来。

但也要注意，专业文件交付不能只看“生成了文件”。应增加校验环节：文件是否可打开、几何是否闭合、尺寸是否一致、图层是否规范、转换后是否丢信息。对于需要安装软件或写入本地的步骤，必须保留人工审批和操作日志。只有“产物可验证”，才谈得上工程可用。

四、数字孪生页面：动态联动与实时刷新才是难点

简单页面生成早已不是难点，真正困难的是复杂页面中的动态联动与实时状态同步。数字孪生类页面通常包含地图、指标卡片、状态面板、告警列表和时序数据视图，表面上只是布局，背后却涉及数据流、状态管理、刷新策略、异常降级和性能约束。

评测此类任务时，应看模型能否识别数据实体之间的关系：地图位置变化是否触发指标刷新，设备状态变化是否同步到告警面板，时间窗口切换是否影响图表与列表。还要看它能否处理实时刷新带来的性能问题，例如节流、增量更新、缓存和失败重试。页面“看起来能跑”不等于“能稳定运行”；演示环境中的一次成功，也不等于在真实数据波动下可维护。

因此，动态页面任务应加入可观测性要求：关键状态是否有日志，数据刷新是否有错误处理，接口失败时是否有降级提示，用户操作是否能回放。对于企业场景，还要考虑权限控制与敏感数据脱敏。智能体可以生成页面骨架和联动逻辑，但最终仍需工程校验与安全审查。

五、报告生成：结构化内容与演讲场景要分开评价

报告生成也是常见评测场景。简单演示文稿与行研报告并不是同一难度：演讲型材料强调信息层级清晰、每页观点少、视觉负担低；行研型材料则强调事实一致性、结构完整、数据来源可追溯、结论与论据匹配。若把两者混为一谈，就容易出现“页面很漂亮但内容不可用”的问题。

评测报告任务时，应检查：大纲是否覆盖关键问题；论据是否与结论一致；数字与引用是否可核验；版式是否服务于阅读；长文档是否保持术语一致；是否能把复杂内容压缩为演讲可读的层级。对于行研报告，还应增加事实校验和人工复核节点，避免模型生成看似合理但无法追溯的表述。智能体可以显著提升初稿效率，但不应替代最终审稿。

六、成本、配额与可运营性

能力越强，成本越需要精算。单次调用价格只是表面，真正应关注单位成功任务成本：包括模型调用、工具执行、格式转换、重试、人工审批和失败返工。若一个任务需要多次尝试才能成功，即使单次价格低，单位成功成本也可能很高。相反，若模型能减少人工步骤、降低返工率，即使单价上升也可能具备价值。

配额管理同样重要。订阅套餐的短时间窗口配额、工具调用限额、并发限制都会影响可用性。工程上应设计模型路由、缓存、重试上限和降级策略：简单任务走低成本路径，复杂任务走高质量路径；重复请求命中缓存；失败任务进入队列而非无限重试；关键任务保留人工接管。只有把成本、配额和稳定性纳入评测，才能判断其是否适合生产环境。

七、工程化落地清单

综合来看，评估此类通用智能体应至少覆盖以下清单：

1. 任务闭环率：能否从输入走到可验证产物，而非停在建议层。
2. 工具调用正确率：工具选择、参数构造、结果解析是否稳定。
3. 产物可验证性：文件能否打开、页面能否运行、报告能否审阅。
4. 权限与审批：本地写入、软件安装、外部上传是否有门禁。
5. 可观测性：日志、审计、回放、成本记录是否完整。
6. 异常恢复：失败后能否定位、重试、降级或转人工。
7. 单位成功成本：包含重试与人工介入后的综合成本。
8. 安全边界：敏感数据、外部上传、本地执行是否受控。

八、结论：审慎乐观，以交付论英雄

宣称进入AGI时代并不等于已经通过工程验证。更合理的看法是：这类通用智能体在工具调用、专业文件生成和复杂页面构建上确实展现出从“会说”到“会做”的进步，但真正落地仍取决于权限模型、产物校验、成本控制和审计能力。评测者不应被单一基准分数或演示效果带走，而应围绕真实任务设计闭环测试；企业用户也不应只看模型价格，而应计算单位成功任务成本与风险成本。把智能体放进沙箱、加上审批、保留日志、验证产物，再谈效率提升，才是面对任何“AGI宣称”时最专业的姿态。