盛溪的博客 https://tangly1024.com/ 畅所欲言、自由评论 Sun, 02 Aug 2026 08:10:00 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en-US All rights reserved 2026, 盛溪 <![CDATA[Agent-后端协作的三种模式]]> https://tangly1024.com/article/Agent-后端协作的三种模式 https://tangly1024.com/article/Agent-后端协作的三种模式 Mon, 13 Jul 2026 00:00:00 GMT

一、Agent-后端协作的三种模式（演进路径）

模式
说明
状态
纯后端无 Agent
Web Coding 直接开发，大模型仅作代码生成辅助工具，无自主决策
传统模式
Skill 接入模式
Agent 独立于后端，通过 Skills（CLI/脚本/Workflow）调用后端能力；Agent 只负责编排与思考
推荐
对话式 Agent
Agent 直接对话操控全部后端能力（取数、AB实验、MySQL巡查等），生成可视化看板
未来方向
Skill 接入模式关键点：
  • Agent 不嵌入后端代码，后端也不感知 Agent 逻辑
  • 可参考项目：GitHub cli anything（README 讲清了"暴露 CLI 给 Agent 控制后端"的原理）
对话式 Agent 安全边界：
  • 严格遵循用户权限隔离
  • 核心系统（删库、管理员权限）不暴露给 Agent
  • 仅开放可读 / 受控写入权限

二、核心工程实现

编排（Orchestration）/ 工作流（Workflow）
  • Agent 推理过程本质是 DAG，应做并发优化（如 A、D 可并行执行），而非线性串行
  • Workflow 用 Prompt 或 Skills 内逻辑约束 Agent 行为边界，防止发散、提高稳定性
  • Harness 工程：限制系统调用边界和脚本规划范围，让 Agent 在有限框架内自由思考
知识库 / 幻觉抑制
  • 建议用纯推理能力的原生模型 + 注入公司私有知识库，避免通用知识和内部知识冲突
  • 用 RAG + 向量数据库做高价值文档召回，解决上下文长度限制

三、技术选型

语言/框架
  • Agent 侧：Python（LangChain/LangGraph）——计算密集型，生态丰富
  • 后端侧：Go/Java/Rust 任意语言，通过 Skills 暴露能力，语言层面完全解耦
网络/基础设施
  • 独立中转网关（如 Model Port）：统一处理外网访问（Web Search）、Token 消耗监控
  • 代理策略：用一台具外网能力的机器（如 Mac Mini）做网关，内网机器统一走网关访问外部资源，保证网络行为可控
 
 
CLI的这种命令行天然适合Agent去操作
https://github.com/HKUDS/CLI-Anything#-real-world-demos
普通 CLI vs "Agent-native" CLI 的区别：
  • 普通 CLI 是给人用的：交互式提示、彩色输出、需要人工判断下一步
  • Agent-native CLI 强调 -json 结构化输出（人读格式 + 机器读格式并存）、无状态可脚本化、错误信息可解析、幂等性强，本质是把 CLI 当函数调用来设计，而不是当终端会话设计
CLI-Anything 做的事情，是把这套"Agent-native 化"变成了自动化流水线：给一个软件的源码/仓库，7 阶段（分析→设计→实现→测试→文档→发布）自动扫描 GUI 操作背后的真实后端调用（比如 GIMP 的 ImageMagick、Blender 的 Python API），生成保留全部核心功能的 CLI 封装，而不是"玩具级"重新实现。这解决的是一个结构性问题：以前想让 Agent 深度操控专业软件，要么自己手写适配（成本高、覆盖窄），要么退化成截图点击（不稳定）。它相当于把"人操作软件"和"Agent 调度软件"这两条路径解耦了。
 
 
]]> <![CDATA[状态机]]> https://tangly1024.com/article/状态机 https://tangly1024.com/article/状态机 Mon, 13 Apr 2026 00:00:00 GMT

形式化定义

状态机(有限状态机 FSM)是一个五元组:
  • S:所有可能状态的集合(比如 {待检索, 已检索, 已生成, 已校验, 完成, 失败})
  • Σ:输入/事件的集合(触发状态转移的东西,比如"检索结果为空"、"重试次数超限"、"用户确认")
  • δ:转移函数,δ: S × Σ → S,即"当前在状态 A,收到事件 X,下一个状态是 B/"
  • s0:初始状态
  • F:终止状态集合(可以有多个,比如"成功完成"和"失败退出"都是终止态)
 
状态机做的事是把这个隐式的"执行到哪了"显式化成一个数据结构。好处:
  1. 可暂停/可恢复:状态存下来,随时能从任意状态继续跑,不需要从头执行
  1. 可检查:循环外部(或者决策模块)可以随时问"你现在在哪个状态",而不需要理解整个执行逻辑
  1. 转移逻辑和状态本身解耦:δ函数可以单独改,不用动每个状态内部具体做什么
 
拿 RAG 场景举例

拿 RAG 场景举例

如果不用状态机,skill 大概是:
线性写死,检索失败或结果质量差就直接崩,或者只能靠 if-else 在同一个函数里硬堆。
用状态机,你先定义状态和转移:
这样,循环体每一轮只需要做两件事:看当前状态是什么 + 根据观察结果查 δ 决定下一个状态。这就是我之前说的"从脚本变成循环体"——循环本身逻辑很薄,复杂度都下沉到状态定义和转移表里。
 
 
]]> <![CDATA[SKU和GMV是什么意思]]> https://tangly1024.com/article/SKU和GMV是什么意思 https://tangly1024.com/article/SKU和GMV是什么意思 Fri, 15 May 2026 00:00:00 GMT
SKU（Stock Keeping Unit，库存量单位）：库存管理的最小单位。同一款薯片，70g 装和 120g 装是两个 SKU；原味和番茄味也是两个 SKU。所以「3000+ SKU」指的是这个品牌在售的、需要分开管理库存的商品规格总数，不是 3000 种零食。
GMV（Gross Merchandise Volume，商品交易总额）：一段时间内成交的订单总金额（通常按下单口径算，含未付款、退货等，所以 GMV ≠ 实际营收）。「月度 GMV 过亿」就是这个品牌一个月的成交流水超过 1 亿元。
放到这道题的语境里：
  • 3000+ SKU → 商品种类多、库存结构复杂，所以才会出现「爆款断货、滞销积压」的结构性矛盾。
  • 月 GMV 过亿 → 体量大，库存周转每多 1 天，压的都是真金白银，60 天周转意味着大量资金沉淀在仓库里。
 
 
 
 
]]> <![CDATA[SDK 是什么]]> https://tangly1024.com/article/SDK 是什么 https://tangly1024.com/article/SDK 是什么 Sat, 27 Jun 2026 00:00:00 GMT
把 JSON 的 HTTP 请求封装好 → 再把返回内容变成 Python 能直接读取的对象
去程封装、回程解析,两头都包。这就是 SDK 的全部本质
 
无论是 OpenAI 还是 Anthropic 的 SDK 都是同样的道理，它们只是两种不同的方言，但是干的事情都是同样的一件事情。
 
notion image

SDK 到底是什么

SDK = Software Development Kit。但在我们这个场景里，它更准确的名字是客户端库（client library）——一包别人替你写好的 Python 代码。你做两件事就能用：pip install openai 把它下载下来，from openai import OpenAI 把它导进你的程序。
它们是两个不同的库，各自匹配各自公司服务器听得懂的"方言"。你不用想象这个区别——你今天亲手经历过：我们就是因为换 SDK，把 agent.py 里一堆字段名改了一遍。这就是全部区别：
同一件事
Anthropic SDK 的说法
OpenAI SDK 的说法
发起对话
client.messages.create()
client.chat.completions.create()
"还要不要工具"的信号
stop_reason == "tool_use"
finish_reason == "tool_calls"
模型想调工具
tool_use 块
tool_calls 列表
工具参数 schema
input_schema
parameters（外面还套 function）
工具结果喂回去
tool_result 块
一条 role: "tool" 消息
骨架（那个 while 循环）一模一样，因为两家干的是同一件事；不同的只是字段名、方法名、数据的包装形状。就像同一份合同，一个用中文写、一个用英文写——内容相同，词不同。
 
 
 
 
 
 
 
 
 
 
 
 
]]> <![CDATA[tool-call具体执行]]> https://tangly1024.com/article/tool-call具体执行 https://tangly1024.com/article/tool-call具体执行 Sat, 27 Jun 2026 00:00:00 GMT
模型不负责具体的调用，它只传递出我要做什么，
比如，我要申请一个工具调用
然后它会指出，我要调用什么 工具名称 和 参数
 
 
 
模型返回的不是执行结果，是一个"调用请求"。
当模型决定用工具，它的响应里会出现一个 tool_use 块，长这样（Anthropic 格式）：
注意：模型只是说"我要用 query_supplier，参数是这个"。它没执行任何东西，也没能力执行——它只产出了这段结构化文本。真正跑代码是你的事。
你接到后，执行分四步：
第四步是关键，也是最多人漏的：把结果塞回对话，再调一次模型。
所以一个完整的 tool-call 是一个回合（round-trip），不是一次单向调用：
这就是 ReAct / Agent loop 的内核——把第四步包进一个 while 循环：只要模型还在返回 tool_use 就继续执行、回灌、再问；直到它返回纯文本（不再要工具），循环结束。
 
 
 
 
 
 
 
 
 
 
 
 
 
 
]]> <![CDATA[Python 协程]]> https://tangly1024.com/article/Python 协程 https://tangly1024.com/article/Python 协程 Fri, 12 Jun 2026 00:00:00 GMT

核心 analogy

协程 = 能暂停和恢复的函数。普通函数一旦调用就跑到底；协程跑到一半可以主动"让出"控制权（await），等条件满足再从断点继续。
 
把 event loop 想成一个单线程的调度员：手里攥着一堆协程，谁卡在 I/O（网络、磁盘）就把谁挂起，转去跑别的，等 I/O 好了再回来。所以是 concurrency（并发）不是 parallelism（并行）——始终一个线程，靠"填补等待空隙"提速。
 

为什么需要它

I/O-bound 场景下，线程大部分时间在 等（等 LLM 返回、等 DB 查询）。多线程能解决但有 GIL + 线程切换开销 + 锁。协程在用户态切换，没有 OS 线程开销，单线程就能扛上万并发连接。
对你做 Agent 直接相关：并行发多个 tool-call、同时打多个 LLM 请求，本质都是用 asyncio 把等待时间复用起来。
 

技术实现

定义与运行
注意：fetch("a") 本身只是返回一个 coroutine 对象，不执行。必须丢给 event loop（await 它 / 包成 Task / asyncio.run）才真正跑。这是新手最常踩的坑。
串行 vs 并发
gather 就是你做 parallel tool dispatch 的核心原语。
Task：手动调度
create_task 和 gather 的区别：前者立刻开始执行并返回句柄，后者是"打包 + 等全部完成"。

await 能 await 什么

只能 await awaitable：coroutine、Task、Future。底层是对象实现了 __await__。asyncio.sleep 是 awaitable，而 time.sleep 是阻塞调用——在协程里用 time.sleep 会卡死整个 event loop，所有协程一起停。这是另一个高频翻车点。

历史包袱（面试可能问）

  • Python 3.4：@asyncio.coroutine + yield from，基于 generator
  • Python 3.5+：原生 async/await 语法糖，语义上和 generator coroutine 同源（都靠暂停/恢复），但成了独立类型
所以协程本质是 generator 的泛化：generator 用 yield 把值送出去，coroutine 用 await 把控制权让出去。
 
一个线程跑 event loop,轮询式地问 OS "谁的 I/O 好了"。某协程要做 I/O 时,把 fd（ file descriptor） 注册给 OS 就让出,线程转身去 resume 其他就绪协程。等待全程由 OS 负责,线程只在彻底没活时才阻塞在 kqueue 上。
 
协程发起网络请求 → OS 给这个连接分配一个 fd(比如 7 号)→ event loop 把"7 号"登记进 kqueue:"盯着 7 号,它可读了喊我" → 线程撒手去跑别人 → 网卡数据到了,内核标记 7 号就绪 → select() 返回"7 号好了" → loop 凭这个号找到对应协程,resume 它。
 
协程要 I/O → 把 fd 注册给 OS → 协程让出 → 线程转去跑别的协程 → OS 处理完 I/O 标记 fd 就绪 → loop 发现后唤醒(resume)对应协程从断点继续。
 
 
 
 
]]>