微店 AI 全栈开发秋招二面：Agent 可验证性与工程边界

《面试题目》

1. 你做过的系统中，哪一部分最能体现你的技术能力？
2. 怎样证明一个 Agent 的执行结果不是偶然成功？
3. 如何控制 Agent 的最大执行范围？
4. 如何设计一个支持多国家法规的知识库？
5. 图片识别结果和文本审核结果不一致时，应该怎样处理？
6. Spring Boot 中如何设计模型调用客户端？
7. Spring Boot 应用中的配置如何避免被错误覆盖？
8. Agent 工具返回大量数据时，如何避免上下文快速膨胀？
9. 如何让 Agent 正确理解工具之间的依赖关系？
10. 如何处理工具调用参数不完整的问题？
11. 如何处理模型返回了合法 JSON，但业务语义仍然错误？

《参考解析》

证明 Agent 不是偶然成功：靠可重复的评测而不是演示。建一套任务集，覆盖正常任务、边界任务、工具失败、数据缺失、权限不足、模型返回异常和多次重试；每次执行都留完整记录——模型与 Prompt 版本、工具列表与版本、每一步的输入输出和状态、工具调用次数与耗时、最终结果与校验结果。指标上不只看任务完成率，还要看关键步骤成功率、人工接管率、重复调用率、平均执行步数、异常恢复成功率和单位任务成本。如果相同输入、相同工具状态下结果差异很大，要把它当 bug 查——查规划约束、随机参数、上下文压缩和工具返回格式，而不是归因给”模型不稳定”。

控制执行范围：从五个维度设预算——最大步数、截止时间、最大工具调用次数、最大 Token 数、成本上限，任一超限即停。比”数量限制”更重要的是”权限限制”：Agent 可以查询商品法规，但不能直接改价、删商品、发布商品；高风险操作拆成 preview 和 confirm 两步，确认令牌绑定用户、资源、租户和有效期，重放也只会执行一次。

多国家法规知识库：不能只按普通文本切分，元数据必须带上国家、地区、法规类型、生效时间、适用类目和版本。查询时国家、类目、生效时间要作为结构化过滤条件下推到检索层，而不是只靠向量相似度——否则德国化妆品的问题会召回到美国的条款。同时保留原文条款号和页码，审核结论必须能回到法规原文。法规更新时，新旧版本在索引层面明确隔离，避免模型同时看到互相冲突的条款；旧版本要标记失效、更新倒排、隔离旧向量、清理相关回答缓存并重跑关键问题。

图文冲突仲裁：先区分两种情况——同一事实的细节差异，还是图片识别出了文本未声明的特征。系统不能让模型直接二选一，而应保留来源与置信度（如 {field, textValue, imageValue, textConfidence, imageConfidence, conflict}）。影响合规结论的冲突必须进人工复核或补充识别；低风险字段才允许按预设优先级处理。最终结论要说明冲突来源，例如「商品描述声明材质为棉，但图片识别疑似含皮革元素，当前无法自动确认，建议补充材质证明」——这让审核结论可解释、可申诉。

模型调用客户端：统一封装超时、重试、流式响应、错误转换、Token 统计和链路追踪，业务代码不许自己拼 HTTP。接口层面暴露 chat / stream / embedding，配置用 @ConfigurationProperties 收口，不同厂商的返回格式在客户端内转成统一内部对象——这样换模型时上层业务不用改。流式用统一的 chunk 抽象，避免每个调用方各自解析 SSE。

配置不被错误覆盖：先明确优先级（命令行参数 > 环境变量 > 外部配置 > 包内 profile 配置），再对关键项做启动校验——模型地址、租户隔离开关、生产日志级别、数据库连接都应在启动时验证，别等运行到一半才炸。用 @Validated + @NotBlank/@NotNull 在配置类上做声明式校验；敏感值走环境变量或密钥管理系统，不提交仓库；启动时输出配置摘要，但绝不打印 API Key 和数据库密码。

工具结果膨胀：工具不该把数据库结果原样回灌。返回前做裁剪和聚合——分页、字段选择、聚合统计、摘要化，只把后续步骤真正需要的原始数据存进任务状态，把引用 ID 返回给模型。同时设单次结果的最大字节数与最大条目数，超限时明确返回 truncated: true 和总数，避免模型误以为已拿到全量。

工具依赖关系：不要只写在自然语言描述里。每个工具声明 requiredStates 和 producedStates，执行前检查前置状态，缺失就直接抛错。固定流程由工作流控制顺序；开放式任务允许 Agent 自己选工具，但依赖校验仍由后端负责——把顺序控制权交出去，但把校验权留下。参数不完整时分三类处理：必须用户提供的（国家、SKU、审核类型）追问；能从上下文可靠推导的自动补；可以安全默认的（分页大小）用默认值。Schema 里写清 required 和 additionalProperties: false，校验失败把错误字段和格式要求回给模型，最多修复有限次数，仍失败就转人工，绝不无限重试。

JSON 合法但语义错误：格式校验只是第一层。要在程序侧加语义校验——字段枚举是否在允许集合内、金额是否在合理区间、证据列表是否非空、引用的条款是否真实存在。像 {"riskLevel":"LOW","evidence":[]} 这种就是典型的”格式合法、结论无据”，规则应该是「高风险结论必须带非空证据，否则降级为待人工复核」。校验失败后只让模型修复失败字段，而不是整任务重跑——既省成本，也避免已完成步骤被重复执行。