（本文大幅度使用ai进行润色） 这里我们主要来看看pi的插件系统 先说结论，看完再回来体会：agent.ts 是底层 loop core，它压根不知道「插件」的存在，只认 beforeToolCall / afterToolCall 这类回调。整个插件系统是 AgentSession 这一层搭起来的，它才是插件的宿主。 所以这篇的主线是：插件从哪来 → 谁托管它 → 它怎么在正确的时刻被

这里我们具体看看一个工具咋定义以及如何被使用我们以ls为例子 创建一个工具123export function createLsTool(cwd: string, options?: LsToolOptions): AgentTool<typeof lsSchema> { return wrapToolDefinition(createLsToolDefinition(cwd

AgentSessionRuntime我们先从代码开始看看，后续再总结整个模块的功能 123456789101112131415export class AgentSessionRuntime { // 提供了两个钩子 // 一个用于重新绑Session // 一个用于在Session失效前执行清理 private rebindSession?: (session: AgentSessi

我们都知道agent本质本就是一个loop，不断循环思考去解决下一步问题，经典的就是ReAct模式 这里我们重点看看pi agent内核是咋写的，依旧以prompt为入口开始看看 prompt123/** Start a new prompt from text, a single message, or a batch of messages. */async prompt(message: A

对一些逻辑较为复杂的点进行记录 执行压缩总共就两种情况 LLM返回上下文超出长度 或者 llm输出长度低于输出maxtoken（我理解为取决于LLM的响应决定是否压缩） 1234567891011121314151617181920212223242526272829303132333435// 还没撞到desiredMaxOutput上限，但是报错了，压缩后重试export function

本次打算对go的io进行一个分析。 go io首先我们来查看一下go io包下的文件树。 12345678910├── example_test.go├── export_test.go├── fs├── io.go├── io_test.go├── ioutil├── multi.go├── multi_test.go├── pipe.go└── pipe_test.go ioutil是一些工具

参考链接1对grpc有非常详细的教程，这里主要讲一些文章中没讲过的。我们主要基于文章最后提供的链接分析一下其中的代码。 我们来看看.pb.go和_grpc.pb.go文件。目前这是我们的pb文件。 12345678910111213141516171819202122232425262728syntax = "proto3"; // 版本声明，使用Protocol Buffer

主要是分析一些比较熟悉的开源项目的github action。 etcdcodeql-analysis.yml12345678910111213141516171819202122232425262728293031323334353637383940414243name: "CodeQL"on: push: branches: [main, release-3.4,

1brc挑战1brc 是Gunnar Morling老哥发起的挑战，这位老哥看起来挺牛逼的。挑战的主要内容页很简单，就是对一个10亿行的文件，进行解析，求出每个城市温度的最大值，最小值和平均值。这幅图里面讲的非常清楚。接下来我将讲一讲我自己的解决思路和方案。 一些前置处理 在src/python下提供了数据产生脚本create_measurements.py <number>。 官方测

ziplist的缺点我们都知道ziplist的插入效率其实是$o(n)$的，redis的解决方案是ziplist不可太长。使用到ziplist的两个上层数据结构分别是dict和zset，其二者有配置hash-max-ziplist-entries和zset-max-ziplist-entries来限制其在底层存储是ziplist状态下的长度。同时我们在这里解释了ziplist递归更新的风险，这将短