技术
技术笔记与教程，从 Runtime 到 Agent 相关的实践记录。
如何实现一个 Jev-like API
业务方提交工单和候选组，服务直接返回 network、device、software 的分数与选择结果，不用处理 token 或解析模型文字。用基础语言模型和 vLLM 自建这样一个类型化决策接口，重点是请求如何变成候选分数，以及单 token、多 token 两条路径如何统一起来。
第七篇：让销售助手学会入库和出库
工具从一个增加到三个：新增 add_inventory 和 remove_inventory 之后，调用代码要不要跟着增加新的判断分支？答案是一份用工具名称对应函数的注册表——这也是程序第一次拥有能修改数据的工具。
第六篇：查不到商品时，模型会不会编一个数字
工具明确返回“没有查到”时，模型是会诚实说明没有数据，还是编一个看起来合理的库存数字？先确认程序能把 None 正确传给模型，再用真实调用观察模型实际怎样回答。
第五篇：模型提出调用，程序执行工具
上一篇只给模型准备了工具说明书；这一篇第一次走完调用全过程——模型看到 Schema、提出调用请求、程序执行函数、把真实结果送回，模型再据此生成最终回答。
第四篇：先给模型一份查库存的说明书
把'查库存'拆成两件事：一个真正能查到数据的 Python 函数，和一份模型能读懂的 Tool Schema。函数负责做事，Schema 负责让模型描述它想做什么——本篇只把这两块准备好，还不让模型真正发起调用。
第三篇：一次回答到底花了多少时间和钱
让 chat() 从只返回一句文本，变成返回一张记录 token、延迟和估算成本的最小收据——先有单次调用的数据，才可能有后续的可观测性。
第二篇：模型调用失败时，程序应该看见什么
真实触发认证、网络和请求这三类失败，观察 SDK 实际抛出的异常，再把它们翻译成一组稳定、可采取行动的应用层错误类型——失败分类不是为了报错更整齐，而是为了让程序知道接下来能做什么。
第一篇：先让程序和模型说上第一句话
在加入工具、记忆或运行循环之前，先只做一件事：让一段 Python 程序把一句话交给模型，再把模型的回答取回来——看清一次最小的 Chat Completion 里，请求边界和模型能力边界分别在哪里。
Agent From Zero：从一次模型调用到可靠 Agent
不先搬出一套框架，而是从一次最小的模型调用出发，亲手搭建一个库存与报价 Agent，再一步步加入工具、运行循环、校验、恢复、记忆、评估和可观测性，看清一个只会生成文本的模型怎样成长为可靠的 Agent。
第六篇：把所有机制重新拼回一个完整场景
前面一路建立起来的容器、Plugin、Effect、Event、依赖生命周期、失败隔离和 Child Context，放在一起以后到底能不能支撑一个像 HelloCordis 那样的真实小场景。
第五篇：失败隔离与 Child Context
当 Runtime 进入更真实的运行环境以后，为什么仅仅有安装、撤销、事件和依赖系统还不够——一个 Plugin 出错为什么不能拖垮整个系统，以及为什么最终需要的不是一个 Context，而是一棵可以继承与隔离的 Context 树。
第四篇：从一次性依赖检查到响应式依赖生命周期
当一个 Plugin 依赖的能力可能在运行过程中出现、消失和恢复时，Runtime 应该如何持续维护它的激活状态——从一次性的 require 检查，走到能长期追踪依赖关系的 inject。
第三篇：为什么 Event Listener 本身也是一种 Runtime Effect
当两个 Plugin 不应该直接互相认识，但其中一个又需要感知另一个做了什么时，Runtime 该怎么组织它们——Event 不是外挂的子系统，而是可以直接复用 effect 和 scope 机制的一种特殊情况。
第二篇：从直接 provide 到 Plugin、Effect 和 Scope
当 Runtime 已经能保存能力以后，谁来安装这些能力，谁来撤销这些能力，以及撤销时为什么不能一锅端——把安装逻辑抽成 Plugin，把撤销绑进 effect，再用 Scope 隔离每个 Plugin 的边界。
第一篇：从空的 Context 到最小 Service Registry
在谈 Plugin、Event 和依赖之前，一个最小 Runtime 至少应该先拥有什么——从一个完全没有行为的 Context 开始，逐步补上“注册能力”“读取能力”“移除能力”这几件最基本的事情。
MiniCordis：从零实现一个插件化 Runtime
接着 Cordis 从零开始教程往前走一步，换一个角度看这个框架是怎么实现的——不复刻 Cordis，而是做一个简化版 MiniCordis，一步步实现关键 feature，理解这些 Runtime 结构为什么会长成现在这样。
第五篇：回头看 Cordis 的核心概念，以及它为什么像 Agent Runtime
把 Context、Plugin、Service、Event、Lifecycle 和 inject 重新收束成一张完整的 Runtime 心智图，并说明它为什么和 Agent Runtime 如此相似。
第四篇：当多个模块共享同一依赖时，会发生什么
只再增加一个同样依赖 Clock 的模块，看依赖图多出一条边时，外部同步逻辑会怎样迅速膨胀成一片胶水代码。
第三篇：从 Greeter 依赖 Clock 出发，理解 inject
当一个能力开始依赖另一个会动态出现、消失和恢复的能力时，系统该如何保持状态一致？inject 从“注入一个对象”变成“让 Runtime 接管依赖关系”。
第二篇：从日志需求出发，理解 Event 和 Lifecycle
一个模块做完事情后，其他模块想感知却又不能直接耦合——手写一个最小事件系统不难，难的是 listener 的创建和清理，最终一定会把我们带到 Lifecycle。
第一篇：从一个变量开始，理解 Context、Service 和 Plugin
当系统里只有一个简单能力时，普通变量就已经够用；改用 Cordis 重写同样的需求后，Context、Service 和 Plugin 分别在替代什么，两者到底从哪里开始分叉。
Cordis 入门：Runtime 基础
为什么一个长期运行、能力会动态变化的系统最后会需要 Context、Plugin、Service、Event、Lifecycle 和 inject——从一个够小的问候程序出发，让需求一步步增长，看清楚这些抽象为什么会自然出现。