网易互娱 Agent开发 一面

这是群里小伙伴投稿的社招

1. 自我介绍

2. 用过 AI Coding 吗，用的什么模型，实际解决了哪些问题

用过，主要用过 Claude、GPT 系列、DeepSeek-Coder 和 Qwen-Coder 这类模型。日常不是简单让它“帮我写代码”，而是把它放到比较明确的工程任务里，比如老接口迁移、单测补齐、复杂 SQL 改写、调用链梳理、异常日志归因、文档生成和代码评审辅助。

AI Coding 真正好用的前提是上下文给得准。大仓库里如果只贴一个报错，让模型猜，效果会很差；如果能提供相关类、接口定义、调用栈、表结构、异常日志和预期行为，它对局部改动的效率提升很明显。但我不会让它直接改高风险链路，涉及事务、权限、资金、状态机、并发控制的代码，必须人工确认和测试兜底。

3. 开发流程中如何使用 AI，怎么避免 AI 生成的代码直接污染主分支

我的流程一般是先让 AI 做信息压缩，再做小范围实现。比如先让它阅读需求、接口文档和旧代码，总结影响面；然后让它生成候选方案；真正落代码时，只允许它改指定文件或指定函数；最后通过单测、静态扫描、代码 review 和灰度验证。

为了避免污染主分支，会把 AI 生成内容全部放在独立分支或 patch 里，并且限制改动范围。对于后端项目，还会让 AI 同时补测试用例和回归点，不能只交实现代码。AI 的价值在于减少重复劳动，但最终上线标准还是编译通过、测试通过、逻辑可解释、影响面可控。

git checkout -b ai/refactor-content-audit
mvn test -Dtest=ContentAuditServiceTest
mvn clean verify
git diff --stat

4. 为什么 RAG 项目不用 Python，而用 Java 做后端主链路

RAG 的算法实验用 Python 很方便，但生产后端不一定适合把主链路放在 Python。Java 在服务治理、线程池隔离、连接池、限流、监控、事务、权限和工程规范上更成熟，和公司已有的 Spring Cloud、MySQL、Redis、MQ、网关体系也更容易集成。

真正的 RAG 生产链路不只是 embedding 和向量检索，还包括文档解析、切分、索引构建、权限过滤、召回融合、rerank、prompt 组装、模型调用、流式返回和结果审计。Java 负责主链路更容易做稳定性治理，Python 可以保留在离线清洗、模型实验或特征处理侧。

5. 项目的需求从哪里来，怎么把模糊需求拆成可落地的 Agent 能力

需求主要来自内容安全运营、创作者工具团队、客服申诉团队和审核质检团队。最开始的需求经常是“能不能让 AI 帮忙判断这段内容有没有问题”，但工程上不能直接做成一个万能问答。要先拆成明确能力：违规识别、规则解释、相似案例检索、改写建议、人工复核摘要、申诉材料生成。

拆完以后还要定义输入、输出和停止条件。比如违规识别必须输出命中的风险类型、证据片段和置信度；规则解释必须引用具体规则条款；改写建议不能改变原意；申诉摘要必须区分用户陈述和系统证据。只有拆到这种粒度，Agent 才能接入工具和评测闭环。

6. 为什么用了 TransmittableThreadLocal，它解决了什么问题，怎么用

普通 ThreadLocal 只能在当前线程里取到值，线程池场景下任务提交线程和执行线程不是同一个线程，请求上下文、traceId、用户身份、租户信息这些变量就可能丢失。InheritableThreadLocal 对线程池也不可靠，因为线程池里的线程通常早就创建好了，不会每次任务提交都重新继承父线程变量。

TransmittableThreadLocal 解决的是线程池任务提交时上下文捕获和执行时上下文恢复的问题。它可以把提交线程里的上下文包装到 Runnable 或 Callable 里，在线程池执行时恢复，执行结束后再清理，避免上下文串号。

private static final TransmittableThreadLocal<String> TRACE_ID = new TransmittableThreadLocal<>();

ExecutorService rawExecutor = Executors.newFixedThreadPool(8);
ExecutorService ttlExecutor = TtlExecutors.getTtlExecutorService(rawExecutor);

public void submitTask() {
    TRACE_ID.set("trace-" + System.currentTimeMillis());
    ttlExecutor.submit(() -> {
        String traceId = TRACE_ID.get();
        log.info("traceId={}", traceId);
    });
}

7. 线程池在项目里是用来干什么的，参数怎么设置

线程池主要用在模型调用、文档切分、向量索引构建、规则解释生成、异步审计落库和消息消费这些场景。参数不能拍脑袋设置，要先区分 CPU 密集型和 IO 密集型。CPU 密集型任务线程数接近 CPU 核心数；IO 密集型任务因为大量等待网络或下游响应，可以设置得更高，但必须配合队列长度、超时和拒绝策略。

在 Agent 链路里，我会按任务类型拆线程池，比如模型调用池、检索池、审计落库池、消息消费池分开。这样模型接口慢了不会拖死审计落库，检索抖动也不会影响核心请求入口。

@Bean("modelExecutor")
public ThreadPoolExecutor modelExecutor() {
    return new ThreadPoolExecutor(
            16,
            64,
            60,
            TimeUnit.SECONDS,
            new ArrayBlockingQueue<>(500),
            new ThreadFactoryBuilder().setNameFormat("model-call-%d").build(),
            new ThreadPoolExecutor.CallerRunsPolicy()
    );
}

8. 你的 MCP 是用来做什么的，为什么不直接让模型调接口

MCP 主要用来把外部工具标准化暴露给模型，比如内容规则查询、历史案例检索、用户处罚记录查询、审核流转、相似文本搜索、风险标签解释等。它不是简单把 HTTP 接口丢给模型，而是把工具名称、输入 schema、输出 schema、权限边界、超时和错误语义统一起来。

如果直接让模型调业务接口，会出现几个问题：接口描述散落在 prompt 里，参数不稳定，权限不好控，工具调用结果不可审计，新增工具也难治理。MCP 的价值是把工具接入从“临时拼 prompt”变成“可治理的能力协议”。

{
  "name": "query_policy_rule",
  "description": "查询内容安全规则条款",
  "inputSchema": {
    "type": "object",
    "properties": {
      "riskType": { "type": "string" },
      "scene": { "type": "string" }
    },
    "required": ["riskType"]
  }
}

9. 大模型怎么知道什么时候使用 MCP，而不是直接回答

不能完全靠模型自由判断，工程上一般会有路由层。先判断用户问题是否需要实时数据、内部系统数据、权限数据或可执行动作。如果问题只是通用概念，可以直接回答；如果涉及规则库、用户记录、工单状态、历史案例、线上配置，就必须走 MCP 工具。

模型侧也会在系统提示词里约束：没有证据不得编造内部数据；涉及具体业务对象必须调用工具；工具返回为空要说明查不到，不能补全不存在的信息。路由层和 prompt 约束一起用，才能让工具调用稳定。

public boolean needMcpTool(UserQuery query) {
    return query.containsBizId()
            || query.needRealtimeData()
            || query.containsInternalPolicy()
            || query.hasActionIntent();
}

10. Spring Boot 自动配置原理是什么，Starter 为什么能做到引入依赖就生效

Spring Boot 自动配置的核心是条件装配。Starter 提供依赖和自动配置类，自动配置类通过 @AutoConfiguration、@ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty 等注解判断当前环境是否满足条件，满足就自动注册 Bean。

早期版本通过 spring.factories加载自动配置类，新版