Skip to main content

106 posts tagged with "AI Agent"

View All Tags
· 6 min read

强化学习强在哪?一句话:它不需要正确答案,只需要对错信号

监督学习从标注数据里找规律,强化学习从环境奖惩里学策略。两者的区别不是"强弱",而是解决问题的类型完全不同——SL 学映射,RL 学决策。

最容易被误解的一点:强化学习的目标不是每次选最优动作,而是最大化长期累积回报。只看眼前奖励的 RL 跟贪心算法没区别,价值函数才是它的灵魂。

Actor-Critic 架构让模型同时扮演"演员"和"评论家"两个角色——一个负责决策,一个负责评判,互相对抗、一起进化,AlphaGo 的底层思路也源于此。

最关键的应用:PPO 算法驱动了 RLHF,让大模型通过人类反馈学会"察言观色"。训练数据见顶的背景下,RL 是提升模型推理能力的核心引擎。

· 6 min read

ClaudeCode 客户端消息流的有序性,本质上是 单写者 + 显式序号 + 受控并发 换来的工程纪律,不是靠运行时去猜消息该怎么排。

要点拆解:

  1. 所有 stream 事件先汇入统一写入通道,由 序号 决定渲染顺序,不按到达时间。
  2. 工具并发被框死在 读可并行、写必串行 的边界内。
  3. UI 层只信任已经定序的快照,从不直接消费裸 SSE,否则就是乱序事故的源头。
  4. 回合作为原子单位,失败整体丢弃,不修补半截回合。

理解这套规则,比追着 SDK 文档更有用。

· 6 min read

OpenCode 客户端保证消息有序,靠的不是排序算法,而是 "按 partID 分桶 + 桶内就地更新" 的状态合并模型。

核心设计 点:

  1. 每个 part 由服务端分配全局唯一 id创建顺序 = 渲染顺序
  2. 后续 part.updated 事件按 id 就地覆盖,不动 partOrder
  3. 断线重连先拉快照、再续 SSE,幂等更新天然无缝衔接

反面教材:早期每次更新都 setMessages([...messages]) 全量复制,消息一长 CPU 直接飙满。Streaming UI 的性能瓶颈从来不在网络,而在前端的更新粒度。

· 9 min read

Karpathy 4 条规则是写给 AI Coding Agent 的行为准则,源自他 2026 年 1 月对 LLM 编码常见错误的观察,核心是先想再写、最小化改动、外科手术式修改、目标驱动

  1. Think Before Coding — 别假设、别掩饰困惑,主动暴露权衡和歧义
  2. Simplicity First — 最小可用代码,不写"以防万一"的抽象和功能
  3. Surgical Changes — 外科手术式修改,只动该动的,只清理自己造成的孤儿
  4. Goal-Driven Execution — 把模糊指令转成可验证的成功标准,让 Agent 自己循环到完成

一句话不告诉 Agent 走哪条路,告诉它什么叫"做完了"。LLM 在"循环到满足具体目标"这件事上异常擅长,给强标准比给详细步骤更有效。

· 6 min read

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

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