文章 on Koi's Blog

Trellis 技术分享资料：大模型科普与 AI Coding 框架

Tue, 21 Apr 2026 20:30:00 +0800

L站原帖链接

https://linux.do/t/topic/2017019

Trellis-codex app

配置codex的自动演进config设置（进行中）

适配codex app的trellis指令大全+使用说明

初始化指令

如果需求不明确，可以使⽤ /brainstorm 命令进⾏头脑风暴（从Harness Engineering，再到 Trellis 落地中，有详细的使用流程）

指令

指令的作用：告诉 AI：现在进入哪一种工作模式。

$start：打开hooks了，不必手动

让 AI 先读当前项目的上下文，再开始工作。

该用的时候：

新开一个旧项目会话，想让 AI 先接上状态
从老线程回来，怕 AI 不记得上下文
AI 明显不知道当前项目情况

$Brainstorm：需求分析前

需求不清的时候，不急着写代码，先一起把事情想清楚。

该用的时候：

你只知道“大概要做什么”，但还没想清楚
一个需求很复杂，不知道怎么拆
你担心 AI 一上来就写错方向

$Before Dev：写/修改代码钱前，是代码规范（单人基本不必考虑）

开始写代码前，让 AI 先读项目规范。

该用的时候：

你准备开始正式改代码
尤其是新功能、重构、多文件修改

$Check：检查代码是否规范（单人不必考虑）

代码写完后，按项目规范检查一遍。

它更偏向：

代码有没有符合规范
有没有明显跑偏
有没有和项目已有风格不一致

该用的时候：

你写完一轮代码
想先让 AI 做一次自查

$Finish Work：判断开发是否完成，可不可以进入测试阶段

准备结束这轮工作前，做一次收尾总检查。

它会关注什么？

这轮改动有没有漏检查
是否需要补规范
是否有未收尾的问题
是否适合进入测试/提交阶段

该用的时候：

你准备结束当前这轮开发
你觉得“差不多做完了”

$Record Session：开发完成后的状态总结记录

把这次工作的结果记下来，方便下次继续。

什么时候用？

这是非常重要的一点：

通常在你已经测试过、并且已经提交之后再用。

也就是：

开发完成
你自己验证/测试
你提交代码
再 record-session

$Check Cross Layer：检查适不适合改动，做支线任务/修改代码

它是什么意思？

一句话：

检查这次改动会不会牵一发动全身。

它适合什么场景？

改接口
改前后端数据流
改数据库结构
改跨模块逻辑

$Update Spec：记录规范

把这次工作里学到的新规范，写回项目规范库。

它为什么重要？

因为 Trellis 不只是帮你当下写代码，
它还想让项目的规则慢慢沉淀下来。

比如你这次发现：

某类接口必须这么写
某种目录结构以后都统一
某种坑以后都要避开

这些都应该写进 .trellis/spec/

什么时候用？

这次开发形成了稳定规则
你不希望以后再重复解释
你想让 AI 下次自动遵守

$Break Loop：死循环后重新分析

当你反复修来修去都不对时，停下来做一次根因分析。

什么时候用？

修 A 坏 B
修 B 坏 A
连续两三轮都在兜圈子
你怀疑自己只是在“止血”，没找到根因

$Onboard

系统学习这个 Trellis 项目怎么工作。

LLM 基础机制：把“会用 API”变成“理解模型边界”

Mon, 20 Apr 2026 22:30:00 +0800

LLM 基础机制

现在的状态非常典型：

已经会用一些 AI 工具；
也已经接触 API；
甚至已经在工作里和 AI 一起做事；

但这并不等于真的理解模型在做什么。

如果这一层不先补上，后面学 Prompt、Function Calling、Tool Use、Agent 工作流，都会很容易变成“会操作，不会解释”。

所以这篇文章的目标不是教我怎么调用某个接口，而是帮我回答一个更关键的问题：

当我说“我在用大模型”时，我到底在用什么？

一、 LLM

很多人在初学阶段都会自然地产生一种错觉：

有了模型，系统就自动“聪明”了；
模型能回答问题，所以它也应该能承担决策、执行、状态管理这些工作；
只要 Prompt 写好，整体系统就会自然变稳。

这类错觉之所以常见，是因为模型的输出看起来太像“理解”。

LLM 是系统中的一个能力模块，不是整个系统。

1. 模型擅长的是什么

大模型最擅长的，其实是：

根据输入上下文预测下一个最可能的 token；
在足够多的训练数据支持下，生成结构上合理、语义上看起来连贯的输出；
对复杂语言任务进行模式匹配、归纳和重组。

换成更工程化的话说，它像是一个：

强大的语言压缩与展开器。

你给它：

问题
上下文
约束
示例
工具结果

它会在这些输入之上生成一个“最像合理答案”的输出。

2. 模型不擅长的是什么

它并不天然擅长：

长期稳定保存状态；
精确记忆很久以前的细节；
永远遵守你的格式约束；
自动知道何时调用外部工具；
为复杂任务自己维持完整的执行链路；
保证在每一次请求中都可靠一致。

也就是说：

模型可以提供“智能”，但不能直接替代系统设计。

这就是为什么招聘里会强调：

任务拆解
Tool Use
多步骤执行
记忆机制
状态管理
失败兜底
稳定性与成本控制

因为一旦你进入真实产品场景，你就会发现：

“让模型答出来” 和 “让产品稳定运行” 是完全不同的两件事。

二、LLM 的最小工作方式：输入、上下文、输出

如果要理解模型，最先要弄清楚的不是框架，而是最基本的工作单元。

1. 输入不是一句问题，而是一整个消息结构

在今天大多数聊天型模型接口里，输入往往不是简单的一句字符串，而是一组消息。

最常见的是：

system
user
assistant

很多人一开始会把它们当成“格式要求”，但其实它们背后代表的是角色分工。

system

负责给模型设定：

角色
任务边界
输出规范
价值倾向或行为限制

它更像是：

系统级指令或规则背景。

user

是这次真实提问者提供的信息。

比如：

我想让你做什么
我关心什么
当前场景是什么

assistant

则是历史对话里模型自己之前说过的话。

它的意义不只是“聊天记录”，而是：

把前面的推理和承诺重新放回当前上下文里。

2. 为什么这点重要

因为很多后续问题都源自你有没有意识到：

模型看到的不是“你脑海里的意图”
模型只看到这次你喂进去的消息结构

这句话听起来简单，但它会直接改变你对很多现象的理解。

比如：

为什么模型明明“上一轮答应了”，这一轮又变了；
为什么 system prompt 里写了规则，它还是没完全照做；
为什么上下文一长，回答开始跑偏。

这些问题本质上都和：

模型到底看到了什么输入

有关。

三、上下文为什么是核心，而不是附属概念

“上下文”这个词很常见，但很容易被讲得过于轻飘。

对工程来说，它其实是最核心的问题之一。

1. 上下文决定模型当前的世界观

模型并不会真正“记住”你之前说过什么。

从使用 AI 到理解 Agent：学习任务与进度规划

Mon, 20 Apr 2026 21:00:00 +0800

一、起点

1. 已经接触过什么

日常会使用 Codex app，也接触 API、号池这类东西。

我知道模型可以被接入使用；
我知道 API 是真实工作流的一部分；
我也已经在用 AI 参与一些实际任务，而不是只停留在看概念。

2. 真正缺什么

缺的不是“再多用几个工具”，而是下面这些更底层的理解：

为什么 Agent 不是简单的“聊天 + 调 API”；
Tool Use / Function Calling 到底解决什么问题；
上下文、记忆、规划、多步执行之间是什么关系；
为什么一个看起来能跑的 Demo，离真实产品还差很远；
延迟、稳定性、成本、失败兜底为什么会在招聘里被反复强调。

3. 不适合的学习方式

基于这个起点，不适合直接走两条路：

不适合路线一：上来就刷框架

比如一上来就学：

LangChain n- LangGraph
Coze
各种 workflow builder

框架会让我“看起来做了很多”，但不代表我真正理解了底层机制。

不适合路线二：上来就做重项目

我当然可以立刻做项目，但如果理论没有补起来，项目大概率会变成：

能跑
但解释不清楚
换一个场景就不会做
面试时说不明白为什么这样设计

二、往 Agent / AI 工程师方向转

如果我的目标只是“把 AI 用顺一点”，那我可能只需要继续熟悉工具、优化提示词、积累一些 workflow 使用经验。

但我现在更偏向的是：

尽快往 Agent / AI 工程师方向转。

要开始补：

技术原理
系统意识
能力分层
工程语境里的抽象能力

换句话说，我不是想成为“会用 AI 的人”，而是想成为：

能理解 Agent 为什么这样工作，并逐步有能力把它做成产品的人。

三、为什么把学习重点放在理论上

1. 现在最需要的是概念地图

需要先把这些词真正分清：

LLM
Prompt
Context
Memory
Tool Use
Function Calling
Agent
Workflow
Planning
RAG
Multi-agent

2. 需要的是“工程语境中的理论”

不是去读纯学术课，也不是要从 Transformer 数学推导开始。

真正要补的是：

这个概念在实际系统里解决什么问题；
它和别的模块怎么连接；
为什么招聘里会看重它；
它的边界在哪里；
它出问题时通常会表现成什么样。

理论优先，但每个理论都必须带着工程问题一起理解。

四、学习主线怎么排：先学什么，后学什么

第一阶段： Agent 的基础骨架

第一组：LLM 基础机制

要搞清楚：

模型的输入输出到底是什么；
system / user / assistant 为什么这样分；
上下文为什么会影响结果；
token、窗口长度、成本、延迟之间是什么关系；
为什么模型并不真正“理解”，却仍然能完成很多任务。

第二组：Prompt / 上下文 / 输出约束

Prompt 到底在控制什么；
为什么有时约束写了但模型不听；
为什么多轮对话会越来越乱；
如何让输出更稳定；
什么时候应该让模型自由回答，什么时候应该强结构化。

第三组：Function Calling / Tool Use

能不能调用工具；
能不能基于工具结果继续执行；
能不能把用户问题变成一串可执行动作。

第二阶段：理解 Agent 为什么能多步执行

1. 任务拆解

一个复杂任务为什么要拆成多个步骤；
拆得太粗和拆得太细分别会出什么问题；
哪些步骤该交给模型，哪些步骤该交给规则或工具。

2. 工作流与规划

什么叫 planning；
什么只是顺序执行，什么才算真正的规划；
一个 Agent 的“思考”本质上是不是状态流转。

3. 多步执行中的状态

当前步骤是什么；
上一步结果如何影响下一步；
中间状态应该保存什么；
失败时怎么继续而不是从零重来。

第三阶段：再补更热、更容易被误学的词

1. RAG

我现在工作里其实还没有明显的知识库 / 检索增强场景，所以 RAG 不是第一优先级。

从一则招聘出发：Agent 工程师学习路线（详细版）

Fri, 17 Apr 2026 20:30:00 +0800

如果把那份 JD 压缩成一句话，它想找的并不是“会调模型 API 的人”，而是能把大模型能力做成可执行、可维护、可上线的 Agent 系统的人。

要逐步补齐这几类能力：

LLM / Agent 基础机制理解
Tool Use / Function Calling / 工作流编排
后端与系统工程能力
RAG / 长上下文 / 状态管理
稳定性、成本、延迟与产品化能力

下面我会按“优先级 → 学习顺序 → 阶段目标 → 产出物”的方式展开。

一、先判断：这份 JD 真正要的是什么

先把招聘需求重新翻译成人话。

1. 它不是单纯的大模型应用岗

如果只是“接 OpenAI 接口、做个对话框、写点 Prompt”，其实不需要写出：

任务拆解
决策逻辑
Tool 调用
多步骤执行
记忆机制
状态管理
任务调度
失败兜底

这些词一出现，说明岗位关注点已经从“模型调用”上升到了“系统设计”。

2. 它也不是纯算法岗

JD 并没有重点要求你训练模型、调底层参数、做学术论文复现，而是反复强调：

API / function calling
外部能力接入
服务架构
状态管理
工程落地
与产品、客户端、算法协作

所以它的理想人选更像：

懂模型边界的工程师，而不是只会调包的应用开发，也不是只做算法的研究员。

3. 它最核心的能力其实是“抽象 + 落地”

我觉得这份 JD 最值钱的一句是：

能从用户问题出发，抽象为 Agent 可执行的流程。

因为这句话本质上要求你具备三层能力：

理解真实问题
抽象成流程
把流程落到系统

这也是为什么后面的学习路线不能只列技术名词，而要围绕“问题 → 流程 → 系统”来安排。

二、学习优先级：什么必须先学，什么可以后置

如果完全从零开始，最容易犯的错误是顺着热词学：

今天看 multi-agent
明天学 RAG
后天跑 Coze
再后天试 LangGraph

最后会变成“每个词都知道一点，但没有一条能独立做成产品的主线”。

所以我建议按下面这个优先级来学。

第一层：必须尽快掌握

这部分决定你能不能进入岗位要求的基本线。

1. LLM 调用基础

至少要熟悉：

Chat Completions / Responses 这类调用模式
system / user / assistant 角色结构
token、上下文长度、温度、成本这些最基本概念
流式输出与非流式输出差异

目标不是成为 API 文档朗读者，而是知道：

一则招聘

Wed, 15 Apr 2026 18:02:00 +0800

深圳智能硬件公司招聘 AI Agent 工程师（25k+） - 非我莫属 - LINUX DO

工作地点：深圳
所属团队：产品与技术团队

职位描述
我们正在构建以 Agent 为核心的产品：它不仅响应用户输入，还能理解上下文、拆解任务，并在多个能力之间做决策与执行。
这个岗位的核心，不是简单接入大模型，而是设计和实现一套可扩展、可演进的 Agent 系统——让 AI 能力在真实产品中稳定运行，而不是停留在 Demo。
你将参与定义：一个 Agent 应该如何思考、如何调用工具、如何在复杂场景中持续工作。

主要职责
设计并实现 Agent 系统架构（任务拆解、决策逻辑、Tool 调用、多步骤执行等）；
构建大模型调用链路（Prompt 设计、上下文管理、多轮对话、记忆机制等）；
设计 Tool Use 体系（API / function calling / 外部能力接入），提升 Agent 的可执行性；
参与 AI 产品核心能力设计，将模型能力转化为稳定、可控的用户体验；
优化 Agent 的稳定性与效果（响应质量、延迟、成本控制、失败兜底等）；
与客户端、算法团队协作，推动 Agent 在真实业务中的落地与迭代；
持续探索前沿 Agent 架构（multi-agent、planning、RAG 等）并评估落地价值。
任职要求

AI / Agent 核心能力（必须）
有 LLM 应用开发经验（OpenAI / Claude / Gemini / Qwen 等）；
理解 Agent 的核心机制（任务拆解、规划、Tool Use、多轮推理等）；
熟悉 Prompt Engineering、Function Calling、上下文管理等关键能力；
有实际 Agent / Copilot / 对话系统项目经验优先。
系统与架构能力
能独立设计复杂系统结构（而不仅是调用 API）；
理解 Agent 在真实产品中的问题（延迟、稳定性、不可控性等）；
后端开发经验（Python / Node.js 等），具备工程落地能力；
熟悉服务架构（API 设计、状态管理、任务调度等）。
产品理解与抽象能力
能从用户问题出发，抽象为 Agent 可执行的流程；
理解“能力 ≠ 体验”，能够将模型能力转化为可用产品；
对复杂交互（对话、任务流、推荐等）有基本判断；
能在不确定性中快速试验并收敛方案。
工程与协作能力
代码结构清晰，有良好的工程规范与可维护性意识；
能与产品、设计、客户端工程师高效协作；
具备强自驱力，能够独立推进复杂问题落地；
持续关注 AI 技术发展，并能判断其实际价值。
加分项
有 multi-agent 系统设计经验；
有 RAG（检索增强生成）、知识库或长上下文处理经验；
使用过 LangChain、LangGraph、AutoGen、Coze 等框架；
有 AI 产品从 0 到 1 落地经验；
有性能优化或成本优化经验（如 token 控制、缓存策略等）。
我们能提供
核心位置： Agent 是产品中枢，你将参与其核心设计；
问题深度：面对的是“如何让 AI 真正可用”的系统级问题；
成长空间：从工程实现走向 AI 产品架构的路径；
团队方式：小团队快速迭代，直接影响产品方向。

md格式大全

Wed, 15 Apr 2026 00:00:00 +0800

这篇文章用来集中记录 Markdown 的常见格式。

以后写博客时，如果忘了某个格式怎么写，可以直接回到这里查。

说明：不同平台对 Markdown 的支持略有差异。这里以个人博客、GitHub 常见写法和 Hugo 常用 Markdown 为主。

1. 标题

Markdown 用 # 表示标题。
# 越多，标题级别越低。

# 一级标题
## 二级标题
### 三级标题
#### 四级标题
##### 五级标题
###### 六级标题

实际效果：

一级标题示例

二级标题示例

三级标题示例

四级标题示例

五级标题示例

六级标题示例

2. 段落

普通文字直接写就是段落。

这是第一段。

这是第二段。

实际效果：

这是第一段。

这是第二段。

3. 换行

Markdown 里普通回车不一定会变成换行。
如果想在同一个段落里强制换行，可以在行尾加两个空格，或者直接空一行分成两个段落。

第一行后面有两个空格 
第二行会换行显示

实际效果：

第一行后面有两个空格
第二行会换行显示

4. 粗体、斜体、粗斜体

**粗体**
*斜体*
***粗斜体***

实际效果：

粗体

斜体

粗斜体

5. 删除线

~~这是一段被删除的文字~~

实际效果：

~~这是一段被删除的文字~~

6. 行内代码

用反引号包住一小段代码或命令。

使用 `hugo server` 启动本地预览。

实际效果：

使用 hugo server 启动本地预览。

7. 代码块

用三个反引号包住多行代码。
可以在开头标注语言，方便高亮。

```powershell
hugo server -D
```

实际效果：

hugo server -D

JavaScript 示例：

function hello(name) {
 return `Hello, ${name}`;
}

console.log(hello('Markdown'));

HTML 示例：

<article>
 <h1>标题</h1>
 <p>正文</p>
</article>

8. 引用

用 > 表示引用。

> 这是一段引用。

实际效果：