13 posts tagged with "Agent Basics"

OpenAI Responses API 与 Chat Completions 的本质差在数据模型：Message 还是 Item。

• Chat Completions 把工具调用挂在 message.tool_calls，执行完再补 role=tool message。
• Responses 把 message / function_call / output 拆成独立 Item，运行时一眼能区分。
• Item 让权限 / 重试 / 审计能挂在具体调用上，而不是糊在 message 上。
• API 只表达「模型建议调什么」，执行安全 / 审批归企业 runtime。
• Responses 支持 previous_response_id，免去手动拼历史，但不解决长期记忆。
• 流式推送：Responses 能告知 item 创建、参数生成、item 完成。
• 结论：Responses 更 Agent-native，但不替代企业 runtime——平台层应走 adapter，业务层不直接绑定 OpenAI 对象。

AI Agent 防 Prompt 注入,核心在工具调用面的四道闸——授权 / 上下文 / 沙箱 / 审计。

• 根因:Transformer 没指令/数据边界,Agent 注入是真金白银损失,不是文案错误。
• 工具调用授权:工具白名单 + 参数 schema 校验 + 高敏感操作必须二次确认。
• 上下文分层:系统 prompt / 用户输入 / 工具结果 标记来源,不让工具返回污染系统 prompt。
• 执行沙箱:工具在隔离环境跑(文件系统 / 网络 / 进程),副作用局限沙箱内。
• 全链路审计:每个 tool call 留痕,事后可回放定位注入路径。
• 间接注入最致命:恶意指令藏网页/PDF/数据库等工具返回内容里。

SSE 和 STDIO 是 MCP 的两种传输方式，区别不在通信模式，在进程边界——STDIO 面向本地进程，SSE 面向远程服务。

• STDIO：客户端 fork 子进程，通过 stdin/stdout 收发 JSON-RPC，零网络开销
• SSE：客户端连远程 HTTP 端点，服务端推送事件，需处理鉴权和网络延迟
• 选择逻辑：本地工具用 STDIO，远程共享服务用 SSE，场景决定选型
• 核心差异：STDIO 进程由客户端管理生命周期，SSE 服务端独立部署
• MCP 演进：原始 HTTP+SSE 已被 Streamable HTTP 替代，不再需要双通道拆分
• 关键提醒：本地工具用 SSE 是自找麻烦，多了端口、CORS、鉴权，收益为零

AI 模型的流式输出本质是单向长文本推送，SSE 比 WebSocket 更合适，多数场景不需要双向通道。

• SSE：基于 HTTP，服务端到客户端单向推送，内置自动重连，零额外握手成本
• WebSocket：全双工双向通信，需要协议升级，实现复杂、资源开销大
• 选择逻辑：AI 问答是客户端发一条请求、服务端流式返回文本，单向通道完全够用
• 双向需求：语音对话、实时协作编辑才需要 WebSocket，纯文本问答不需要
• 坑 ①：HTTP/1.1 下同一域名最多 6 个 SSE 并发连接，多标签页可能占满
• 坑 ②：组件卸载时忘记手动关闭 EventSource，连接不会自动释放，导致内存泄漏

意图识别不能全丢给大模型——面试这么答，基本就掉到「只会调 API」那一档了。

1. 三大问题：全丢大模型 → 延迟 500ms-3s / 成本 / 稳定性全面崩盘。
2. 规则层：35% 高频走关键词 / 正则 / 状态机，规则数量严控。
3. 上下文层：55% 走小模型或语义匹配，难点是 DST。
4. 工具层：仅 10% 复杂请求兜底走 LLM，必须配超时降级。
5. 核心思想：能用规则解决的不走模型，能用小模型解决的不走大模型。
6. 面试模板：先点三大问题 → 再讲三层漏斗 → 最后落观点。
7. 关键数字：90% 请求前两层解决掉，根本不需要惊动大模型。