腾讯 大模型应用开发 一面

1. 项目里是把 skill 直接塞进 system prompt 的，如果 skill 太多，占用上下文窗口太大，怎么处理

不能把所有 skill 常驻塞进 system prompt，这样会带来三个问题：上下文窗口被占满、候选技能噪声太大、模型在选择 skill 时更容易混淆。更合理的方式是把 skill 做成外部注册表，system prompt 里只保留最小规则和调用协议，真正的 skill 描述按需动态注入。

常见做法是先做一层 skill routing。可以用规则、分类模型或者向量检索先筛出 topk skill，再把这几个 skill 的 description、参数 schema 和 few-shot 示例拼进 prompt。如果 skill 本身很长，还要把 skill 信息拆成摘要版和完整版，先注入摘要，模型确定要调用后再加载详细说明。这样可以显著压缩 token。

from sentence_transformers import SentenceTransformer
import numpy as np

skills = [
    {"name": "weather_query", "desc": "查询天气，输入城市，返回天气和温度"},
    {"name": "stock_query", "desc": "查询股票，输入代码，返回实时价格"},
    {"name": "order_query", "desc": "查询订单，输入订单号，返回订单状态"}
]

model = SentenceTransformer("all-MiniLM-L6-v2")
skill_vecs = model.encode([x["desc"] for x in skills], normalize_embeddings=True)

def retrieve_skills(query, topk=2):
    qv = model.encode([query], normalize_embeddings=True)[0]
    scores = np.dot(skill_vecs, qv)
    idx = np.argsort(scores)[::-1][:topk]
    return [skills[i] for i in idx]

print(retrieve_skills("帮我查一下北京今天天气"))

2. 如果两个 skill 实际内容不一样，但是 description 很相似，导致 agent 每次加载错 skill，怎么解决

description 相似时，单靠自然语言匹配很容易误召回。解决思路是给 skill 增加更强的判别信息，而不是继续堆模糊描述。

第一步是把 skill 从纯文本 description 升级成结构化定义，包括适用场景、禁用场景、输入参数、返回格式、前置条件、失败条件和调用示例。第二步是做两阶段选择，先召回 topk，再让模型根据参数约束和样例做 rerank。第三步是加入负样本示例，明确告诉模型什么问题不应该调用这个 skill。第四步是执行前做 schema 校验和 rule check，即使模型选错，也不能继续误调。

如果两个 skill 语义长期接近，通常还要考虑在系统设计层面合并成一个 skill，再由内部参数路由，不然前面再怎么写 prompt，后面也会持续混。

skills = {
    "weather_query": {
        "desc": "适用：天气、温度、降雨。禁用：空气质量、AQI。",
        "required_args": ["city"]
    },
    "air_quality_query": {
        "desc": "适用：AQI、PM2.5、空气污染。禁用：天气、降雨。",
        "required_args": ["city"]
    }
}

def choose_skill(query):
    if any(x in query for x in ["AQI", "PM2.5", "空气质量", "污染"]):
        return "air_quality_query"
    if any(x in query for x in ["天气", "温度", "下雨"]):
        return "weather_query"
    return None

print(choose_skill("上海今天AQI多少"))

3. Agent 设计里你觉得最重要的部分是什么

最重要的是上下文工程。Agent 最终不是单轮问答，而是一个持续决策系统。模型能看到什么信息、这些信息的顺序和优先级是什么、哪些内容是规则、哪些内容是证据、哪些内容只是历史状态，这些都会直接影响 Agent 的稳定性。

上下文工程做得好，模型会更像一个受控执行器，知道当前目标、约束条件、可调用工具、历史状态和输出格式。上下文工程做得差，模型即使能力强，也会出现目标漂移、工具误选、记忆污染、长对话失真和推理跑偏。

所以 Agent 设计的核心不是“给模型更多信息”，而是“给模型正确的信息”。

4. 上下文工程有哪些要注意的点

首先要做角色隔离，system、developer、user、tool output、memory 的优先级和边界要清楚，不能把外部文本和系统规则混在一起。其次是信息裁剪，只保留当前任务相关的内容，避免把所有历史对话、所有检索结果和所有工具说明一股脑灌进去。

再往下是格式控制。结构化上下文通常比纯自然语言更稳，比如工具结果尽量用 JSON、任务状态单独字段化、长历史做摘要而不是堆原文。还有一点很重要，就是上下文中的来源可信度必须分层，系统规则优先于用户输入，工具结果优先于模型猜测，知识证据优先于无依据生成。

如果是长任务，还要做上下文压缩和过期淘汰，不然越到后面越容易发生状态漂移和旧信息污染新决策。

5. 你怎么设计 Agent 的长期记忆写回策略、衰减策略和冲突消解

长期记忆不能等价于“把所有历史都存起来”。真正可用的长期记忆必须回答三个问题：什么值得写回、什么时候应该忘、冲突信息怎么处理。

写回策略上，通常只保存高价值稳定信息，比如用户偏好、身份属性、长期任务目标、反复出现的业务事实，而不是每一句对话都入库。写回时最好做结构化抽取，比如把“用户更喜欢用 Python”写成 profile 字段，而不是原文整段存储。衰减策略上，记忆需要有时效性和权重，短期热点信息可以高权重，但随着时间衰减；长期稳定偏好可以低频刷新但不轻易删除。冲突消解上，一般要结合时间戳、来源可信度和置信度，新的高可信事实覆盖旧事实，低可信内容只作为候选，不直接替换。

如果更严格一些，可以把长期记忆设计成事件流 + 物化视图。也就是所有记忆写入先存成 event，再异步聚合成 profile。这样既方便审计，也方便回滚。

from dataclasses import dataclass
from time import time

@dataclass
class MemoryItem:
    key: str
    value: str
    score: float
    ts: float
    source: str

memory_store = {}

def write_memory(key, value, score=0.8, source="dialogue"):
    old = memory_store.get(key)
    item = MemoryItem(key, value, score, time(), source)
    if not old:
        memory_store[key] = item
        return
    # 新信息优先级 = 置信度 + 时间新鲜度
    if item.score >= old.score or item.ts > old.ts:
        memory_store[key] = item

write_memory("language", "Python", 0.9)
write_memory("language", "Go", 0.4)
print(memory_store["language"])

6. 你怎么做并行 Tool Calling，既提升吞吐又保证一致性和可回放

并行 Tool Calling 的核心不是“同时调多个接口”，而是要解决依赖关系、状态一致性、结果合并和失败回滚。只有互不依赖的工具才能并行，比如天气查询和汇率查询可以一起发；如果后一个工具依赖前一个工具的结果，就必须串行。

一致性上，一般不会让多个工具直接修改共享状态，而是采用“工具执行结果先写到临时观察区，再由调度器统一合并”的方式。这样可以避免并发写导致状态污染。可回放则要求每次调用都带 trace_id、step_id、输入参数、输出结果和耗时，最后组成完整执行 DAG。失败处理上可以按工具粒度重试，不能因为一个工具超时就把全部结果丢掉。

如果涉及副作用操作，比如发消息、创建订单、提工单，并行执行前通常还要加幂等键，不然重复重试会造成真实业务重复写入。

import asyncio

async def weather(city):
    await asyncio.sleep(1)
    return {"tool": "weather", "data": f"{city} 25度"}

a