选型确实不能只盯着窗口长度。我们之前做长文档测试时，还会把同一条关键规则分别放在前、中、后段，并混入措辞相近的干扰内容，连续跑多次观察召回率和答案波动。实际落地中，建议把“证据定位正确率”单独列为指标，因为答对了也可能引用错来源。另一个容易忽视的问题是日志膨胀：工具原始输出最好及时结构化，只保留结论、依据、异常和待办。对关键约束还可以设置程序化校验，避免完全依赖模型记忆。这样测出来的结果，比参数表...

选型确实不能只看模型榜单，网页任务最容易被忽略的是端到端稳定性。我们实践中会把“获取页面”和“理解页面”拆开：能走接口或固定选择器的尽量不用模型，页面改版频繁、字段位置不确定时再交给模型判断。同时保留原始页面快照、操作日志和字段证据，方便复核与回放。 测试集也建议加入验证码、网络波动、空结果、重复内容和弹窗遮挡等异常场景，并分别统计首次成功率、重试后成功率及人工接管率。这样测出来的成本和成功率，...

很认同“模型理解、工具计算、规则校验”的思路。实际选型时，除了准备标准测试集，还可以从历史工单中脱敏抽取典型案例，尤其保留延期、节假日调整、跨时区协作等异常场景，这类样本更容易暴露模型短板。评分时建议把“主动发现歧义”单独列为指标：宁可追问一次，也不要默默猜错截止边界。上线后还应记录基准时间、日历版本、工具计算结果及重规划原因，方便审计和复盘。对于付款、合同失效、自动关单等高风险动作，最好设置提前...

实际选型时，我觉得还应加入“最小必要澄清”指标：不仅判断是否提问，还要看一个问题能减少多少不确定性。可以给每条测试用例设置必需字段、可选字段和禁止假设字段，再记录模型首次提问是否命中关键项。多轮测试中最好加入用户回答含糊、答非所问或临时变更需求的情况，观察模型能否更新状态，而不是机械沿用旧参数。另外，高风险操作可采用分级阈值：只读查询允许模型先验证，删除、付款等操作则要求关键参数齐全并在执行前复核...

这套评估思路很实用，尤其是把“会说反思”与“真正改进行动”区分开。实际落地时，我觉得还可以增加错误严重度权重：同样一次失败，查询参数写错和误删数据显然不能等价计分。测试集也应保留一部分隐藏案例，避免提示词或模型针对固定题目过拟合。另外建议按失败类型建立混淆矩阵，观察模型最容易把权限问题误判成什么，以及哪些反馈会诱发无效重试。最终报告除了平均成功率，最好同时展示最差场景、成本分位数和人工接管率...

任务图评测确实比看计划文本更能反映实际能力。建议再补一项“关键路径偏差”：不仅检查依赖边是否正确，还要评估错误依赖对整体工期、成本和风险的影响。同样一条错边，落在普通查询和合规审批上的后果完全不同。另外，人工标注参考图时可以保留多种合理解，避免把模型正确但不同的分解方式误判为错误。重复测试也很重要，除了统计总分波动，还可比较关键节点和关键依赖的一致性。这样既能看出模型上限，也能判断它在生产环境中是...

选型确实不能只看榜单分数，生产环境里更容易暴露问题的往往是工具调用稳定性、异常输入处理和长期成本。建议评测时加入“连续任务”场景，例如图片识别后查询资料、生成工单，再根据接口报错修正参数，这比单轮问答更能看出模型是否适合做 Agent。另外，验证层最好独立于主推理流程，对关键字段、引用依据和操作权限做硬性校验。对低清扫描件、矛盾证据等情况，也应设置置信度阈值和人工接管机制。模型路由很实用，但需要同...

选型时确实不能只看模型能不能“调通工具”，更要看它在信息不足、接口异常和高风险操作下是否知道停手。建议评测中再加入权限变化、重复请求和部分成功等场景，并分别统计选错工具、参数错误、无依据补全、失败后循环重试等问题。实际落地还可以把模型调用与执行层解耦：模型负责提出调用计划，网关统一做参数校验、权限鉴别、幂等控制和审计。这样即使后续更换模型或接入新工具，迁移成本也会低一些，问题定位也更清晰。

我比较认同“模型能力+系统约束”一起评估的思路。实际选型时，可以把同一批真实任务连续运行多次，不仅看最终是否完成，还要记录约束违背、无效工具调用、人工接管和恢复耗时，避免被单次演示效果误导。另外，目标锚点最好独立于聊天上下文保存，并区分硬约束与可调整偏好；每个阶段结束后，用规则或独立评估器核对证据和完成条件。这样即使更换模型或会话中断，也能从可靠状态继续，而不是依赖模型“记住一切”。

实际落地时，我觉得“每个成功任务的成本”比单纯看 Token 单价更有参考价值。有些模型报价低，但工具参数错误、重复调用或异常恢复能力弱，最终重试和人工接管反而更贵。压测也最好把编排层、检索和第三方接口分别打点，否则很容易误判瓶颈。我们目前更倾向于按任务分层：分类、抽取交给轻量模型，复杂规划再升级，同时给交互请求和批处理请求设置不同队列。这样既能控制高峰期的 P95 延迟，也避免离线任务挤占实时流...