真实面经题目 · 原创解析
这道题考察如何把现成 Coding Agent 或通用 Agent 平台做成某个业务域可用的工程系统。回答不能停留在“加提示词”或“接几个工具”，而要围绕数据边界、权限隔离、工具契约、领域知识 RAG、任务流程、评测集、灰度发布、监控和人工接管设计。重点是让通用 Agent 只在授权数据和明确工具能力内行动，用可回放、可评测、可审计的方式逐步扩大自主能力。
基于 Claude Code 这类现成 Agent 做领域适配，我会先定义边界，再接能力。第一步是数据边界：明确 Agent 能读哪些仓库、文档、工单、日志和配置，哪些是密钥、用户隐私、生产数据或跨租户数据，默认最小权限，并对上下文、RAG 索引和工具返回做脱敏与审计。第二步是工具接入：不要把所有私有系统直接暴露给模型，而是用 typed tool 封装成小而明确的动作，例如查工单、读指标、创建变更单、跑测试、生成 patch，每个工具有 schema、权限、超时、幂等、回滚和风险等级。第三步是领域 RAG：把规范、架构文档、接口契约、故障手册和历史案例做成可版本化知识库，检索结果带来源、时间、适用范围和权限标签，避免过期知识误导。第四步是工作流适配：把常见任务拆成计划、检索、工具调用、修改、验证、交付和人工审批节点，高风险动作必须停在审批。第五步是评测：构造真实领域任务集、离线回放工具、期望行为和禁用行为，评估任务完成率、误操作、越权、幻觉、测试通过率和人工介入率。最后是监控：记录 trace、工具调用、检索证据、diff、验证结果、成本延迟和失败原因，线上从只读建议开始灰度到低风险自动执行。
领域适配的目标不是让通用 Agent 知道更多口号，而是让它在特定业务域内更可靠地完成任务。需要先定义任务范围，例如代码修复、值班排障、文档问答、工单处理或配置检查；再定义成功标准、禁止动作和人工接管点。范围不清会导致工具越接越多但效果不可控。
数据边界要覆盖读取、索引、缓存、日志和输出。Agent 能访问的仓库、文档、监控、工单和数据库必须按租户、项目、角色和任务授权；密钥、个人信息、生产敏感数据和跨域内容默认不可进入上下文。RAG 索引也要继承权限标签，不能因为被向量化就绕过原系统权限。
工具接入应采用明确 schema、最小动作和宿主侧校验。每个工具说明输入输出、权限、超时、幂等性、失败码、风险等级和审计字段。读工具、写工具、生产工具要分级；写操作最好先生成计划或变更单，再由审批或验证门禁决定是否执行。
领域知识库应包含架构原则、代码规范、接口文档、运行手册、常见故障、评审规则和历史事故复盘。切片时保留标题层级、版本、更新时间、适用服务和负责人等元数据。检索后还要重排和冲突检测，避免旧手册、废弃 API 或不适用服务被当成当前规则。
现成 Agent 往往具备通用循环，但领域落地需要把任务流显式化：需求理解、上下文收集、计划、工具调用、产出、验证、审批、交付。不同任务可以有不同 policy，例如只读排障允许查日志和指标，代码修复允许改测试环境分支，生产变更必须生成单据并等待批准。
评测要从真实任务抽样，构造可回放的输入、仓库快照、工具模拟和期望结果。指标包括任务完成率、正确修复率、测试通过率、工具调用成功率、越权尝试率、幻觉引用率、误写率、平均人工介入次数、成本和延迟。还要有 adversarial case，例如提示注入、过期文档和权限不足。
建议从 read-only advisor 开始，让 Agent 只分析、总结和给建议；随后开放低风险 patch 生成和本地测试；再灰度到受限目录自动修改；最后才考虑带审批的生产工具。每一级都要有回滚、审计和阈值，例如失败率或越权率超过阈值自动降级。
线上要记录完整 trace：用户输入、检索证据、提示版本、工具调用、返回摘要、diff、测试结果、审批决策、最终输出和用户反馈。监控维度包括成功率、失败类型、人工接管、工具错误、RAG 命中、stale evidence、token 成本、延迟和安全拦截。日志本身也要脱敏和分级保留。
领域适配是闭环系统。失败案例要回流到评测集和知识库，工具 schema 过宽要收窄，常见多步任务可以沉淀为更稳定的工作流或技能。不要把每次失败都靠提示词补丁解决，能用权限、工具、测试和数据治理解决的应放在宿主系统。
索引写入时要把租户、项目、角色、密级和数据状态作为权限标签保存，查询时先用当前用户和任务上下文做权限过滤，再进行向量召回或重排。检索结果返回前还要脱敏和审计。不能把所有文档混进一个无权限边界的索引，也不能只依赖模型自觉不引用。
过宽工具会让模型组合出未预期操作，例如越权查询、批量写入或绕过审批，失败时也难定位责任。应按业务动作拆成小工具，例如查指标、读工单、生成变更单、运行测试、提交 patch，并为每个工具设置参数白名单、风险等级、幂等语义和宿主侧校验。
可以从历史工单、代码修复、值班排障和文档问答中抽样，脱敏后保留输入、上下文快照、工具模拟返回、期望结果和禁止行为。评测集要包含成功路径和失败路径，覆盖权限不足、旧文档误导、工具异常、测试失败和需要人工审批的情况。
控制应放在宿主系统和工具层，而不是只写在提示词里。Agent 可以生成计划、变更说明和候选 patch，但真正调用生产写工具前，应由策略引擎检查风险、权限、审批状态和验证结果。这样即使模型试图越过流程，工具也会拒绝执行。
需要完整 trace，把检索到的证据、重排分数、工具输入输出、模型中间计划、diff、测试结果和人工反馈关联起来。复盘时先看证据是否过期或无权限，再看工具是否返回错误或超时，最后判断模型是否误读证据或选择了错误动作。
至少要在离线和灰度任务中证明任务完成率、测试通过率、越权拦截率、误操作率、人工回滚率、P95 延迟和成本都稳定达标。还需要覆盖高风险负例，确认工具审计、审批、回滚和降级可用。没有这些门槛，自动执行会把偶发错误放大成生产风险。
