影石 AI开发 一面(日常)

1. 自我介绍

2. TCP 和 IP 的职责边界是什么，为什么说“HTTP 基于 TCP，TCP 基于 IP”这个表述只对了一半

IP 负责尽力而为地把报文从源地址送到目标地址，它不保证到达、不保证顺序，也不保证不重复。TCP 建立在 IP 之上，提供有连接、可靠传输、流量控制、拥塞控制和按序交付。HTTP 是应用层协议，它依赖传输层提供的可靠字节流，但 HTTP 本身并不“知道”底下是不是 TCP，也可以跑在 QUIC 上。所以“HTTP 基于 TCP”对传统 HTTP/1.1 和 HTTP/2 是对的，但对 HTTP/3 就不成立；“TCP 基于 IP”则更准确，因为 TCP 的寻址和转发确实依赖 IP 层。

3. TLS 握手里为什么必须有随机数、证书验证和密钥交换，这三者各自解决什么问题

随机数用来保证每次会话的密钥材料不同，避免同样的明文在不同连接里导出相同结果；证书验证解决的是“你到底是不是我要连的那个服务端”；密钥交换解决的是“不把会话密钥明文传输也能协商出共享密钥”。如果没有随机数，重放和模式复用问题会变严重；没有证书验证，中间人攻击几乎无法防；没有密钥交换，只能把密钥直接发出去，传输链路本身就会泄露秘密。TLS 的安全不是靠某一个步骤，而是这些环节共同组成的信任和保密链条。

4. HTTP/1.1、HTTP/2、HTTP/3 的核心差异是什么，为什么 HTTP/2 解决不了所有延迟问题

HTTP/1.1 的主要问题是连接复用能力弱，容易出现队头阻塞和大量短连接。HTTP/2 通过二进制分帧、多路复用和头部压缩降低了连接开销，但它仍然跑在 TCP 之上，只要底层 TCP 某个包丢失，整个连接上的所有流都会受到影响。HTTP/3 把传输层换成 QUIC，把多路复用做到用户态传输协议上，流之间的丢包影响被隔离开，所以更适合高抖动网络。HTTP/2 已经解决了很多应用层问题，但没法绕开 TCP 层的队头阻塞。

5. 如果一个大模型要调用外部工具，协议层至少要解决哪几件事

至少要解决工具发现、参数约束、调用权限、超时控制、返回结构和审计追踪。工具发现决定模型“看得到哪些能力”；参数约束决定模型能不能稳定地产出可执行输入；调用权限避免模型越权访问；超时控制防止工具阻塞拖垮对话；返回结构决定结果能不能被继续消费；审计追踪则负责回放“模型为什么调了这个工具、输入是什么、结果是什么”。没有协议层，这些问题会散落在业务代码和 prompt 里，系统会越来越不可控。

6. function call 的本质是什么，为什么它不是“模型真的去执行了代码”

function call 的本质是模型生成了一段满足约定 schema 的结构化调用意图，而不是真正直接在模型内部执行函数。模型只负责判断“该不该调、调哪个、参数长什么样”，真正执行的是外部宿主环境。也就是说，模型输出的是调用计划，执行权仍在系统侧。这个区分非常关键，因为它意味着权限控制、幂等、重试、回滚和日志都应该由宿主系统负责，而不是寄希望于模型自己“足够聪明”。

{
  "tool": "query_case_detail",
  "arguments": {
    "caseId": "A202604160091",
    "needTimeline": true
  }
}

7. Skill、Tool、MCP 三者在工程分层上分别是什么，不能混着答

Tool 是最底层的可执行能力单元，比如查订单、执行 SQL 模板、获取监控指标。Skill 是任务级能力封装，强调“为了完成某类任务，需要按什么规则组合若干工具和上下文”。MCP 更偏协议层和接入层，解决的是工具如何被发现、描述、调用和治理。简单理解就是：Tool 回答“能做什么动作”，Skill 回答“怎么把动作组织成一类能力”，MCP 回答“这些能力如何标准化暴露给模型”。把三者混为一谈，最后通常会导致调用链难治理、能力边界不清、调试成本极高。

8. 如果一个系统里注册了很多 Skill，模型怎么知道当前该选哪一个，而不是随机命中

真正有效的方法不是把所有 Skill 平铺给模型，而是做前置路由。路由层通常结合意图识别、任务分类、上下文状态和权限范围先筛一轮，把不相关 Skill 从候选集合里去掉，然后再让模型在有限集合内决策。更进一步，Skill 描述要具备明显的边界和互斥条件，否则模型会出现“能力重叠时随机命中”的问题。Skill 数量上去后，如果没有路由层，模型选择本身就会成为一个新的不稳定源。

9. 把所有 Skill 的说明都塞进上下文是不是就等价于“拥有全部能力”，为什么这种做法在工程上很危险

不是。把所有 Skill 说明塞进上下文只会让模型“看到很多描述”，但并不等于它具备稳定的调用决策能力。首先上下文会迅速膨胀，带来 token 成本和干扰项；其次相似能力之间会互相污染，导致选择不稳定；再者，权限边界根本不能靠自然语言说明保证。工程上真正危险的是你以为模型“都知道了”，实际上它只是看到了很多文字，而不是进入了一个受控能力系统。

10. A2A 协议类方案的价值在哪里，它和单模型工具调用不是一个层面的东西

A2A 更强调智能体之间的协作通信，处理的是“一个智能体如何把任务委托给另一个智能体，如何传递上下文、状态和结果”。而单模型工具调用解决的是“当前模型如何调用某个外部能力”。前者更偏多角色、多步骤、多状态迁移的系统设计，后者更偏单轮执行动作。A2A 的价值在于把复杂任务拆给不同职责的执行体，但同时也带来状态同步、重试语义和协作成本的问题。

11. 多 Agent 系统里最难处理的不是规划，而是状态一致性，你会怎么回答这个问题

多 Agent 最大的问题是每个 Agent 都会形成自己的局部事实视图，如果没有统一状态源，很容易一个 Agent 在用旧上下文，另一个 Agent 已经进入新阶段。解决方式通常是引入共享状态存储，把任务阶段、关键变量、工具结果和可见性范围显式管理，而不是靠聊天记录隐式传递。多 Agent 真正稳定的前提不是“分工明确”，而是“所有 Agent 都围绕同一份状态事实工作”。

task_state = {
    "task_id": "risk_review_2048",
    "phase": "evidence_collecting",
    "slots": {
        "merchant_id": "m_9912",
        "rule_version": "v3.12",
        "c