AI 时代信息爆炸——MCP、RAG、Multi-Agent、Agentic Workflow……新概念一个接一个,每隔几周就有新的框架冒出来。很容易陷进去,感觉 Agent 是一个高深莫测的东西,离自己很远。

但如果你亲手写过一遍(在 AI 帮助下,只需要一个上午),就会发现:Agent 本身的代码比大佬们写的控制器和转发面简单多了。 核心逻辑就是一个 for 循环,加上几个工具调用。

这个 Workshop 的目的就是祛魅——把地基翻出来看清楚。从一个 223 行的最小 Agent 出发,一步步演进到具备权限控制、任务规划、技能加载、上下文压缩的完整系统。每一版只解决一个问题,每一行代码都有来处。

看完之后,那些概念还会存在,但它们背后的地基你已经摸清楚了。雾里看花,变成近在眼前。

v1: LLM 调用 + Agent Loop + 单工具 (223行)

最简单的 Agent 实现:一次 LLM 调用 + 一个 while 循环 + 一个计算器工具。核心公式:Agent = LLM调用 + Loop + 工具执行 + 上下文累积。

1. LLM 调用接口 (glm.go)

我们用标准 HTTP POST + JSON body 与 LLM 交互,本质上是遵循 OpenAI Chat Completions API 规范——这是业界事实标准,GLM、Claude、GPT 等主流模型都兼容它。我们把 messages(对话历史)和 tools(工具描述)序列化成 JSON 发过去,LLM 服务端收到的只是一段普通的 HTTP 请求体。

有意思的地方在于:我们从未在 prompt 里告诉 LLM “请用 JSON 格式回复”,但当我们传入 tools 参数时,模型会自动在响应里输出结构化的 tool_calls 字段。这是因为模型在训练阶段(SFT + RLHF)就已经被大量”工具调用示例”微调过——它学会了:一旦上下文里出现工具定义,就应该用约定格式声明调用意图,而不是用自然语言描述。这个行为是编码在模型权重里的,不依赖任何运行时的格式指令。因此,json.Unmarshal 能稳定解析出 tool_calls,不是因为我们约束了输出,而是因为模型自己知道该怎么做。这两个 struct 的字段名和 JSON tag 与 API 规范一一对应,Go 的标准库会自动完成映射:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

type Message struct {
Role      string     `json:"role"`
Content   string     `json:"content"`
ToolCalls []ToolCall `json:"tool_calls,omitempty"`
}

type ToolCall struct {
ID       string `json:"id"`
Type     string `json:"type"`
Function struct {
Name      string `json:"name"`
Arguments string `json:"arguments"`
} `json:"function"`
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

func (c *GLMClient) Chat(ctx context.Context, messages []Message, tools []map[string]interface{}) (Message, error) {
reqBody := map[string]interface{}{
"model":    "glm-5",
"messages": messages,
}
if len(tools) > 0 {
reqBody["tools"] = tools
}

jsonData, _ := json.Marshal(reqBody)
req, _ := http.NewRequestWithContext(ctx, "POST", c.url, bytes.NewBuffer(jsonData))
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Authorization", "Bearer "+c.token)

resp, err := http.DefaultClient.Do(req)
if err != nil {
return Message{}, err
}
defer resp.Body.Close()

body, _ := io.ReadAll(resp.Body)

if resp.StatusCode != 200 {
return Message{}, fmt.Errorf("API error: %s", string(body))
}

var result struct {
Choices []struct {
Message Message `json:"message"`
} `json:"choices"`
}
json.Unmarshal(body, &result)

return result.Choices[0].Message, nil
}

2. Agent 主循环 (main.go)

这里有两层循环,职责完全不同。外层是对话轮次——用户每发一条消息触发一次;内层才是真正的 Agent Loop,处理单条消息内可能发生的多轮工具调用。

LLM 不一定一次就给出最终答案。比如”先算 10+5,再把结果乘以 2”,它需要先调用一次 calculator、拿到结果、再调用第二次才能回答。内层 for i := 0; i < 10 就是这个循环:有 tool_calls 就执行工具、把结果追加进 messages、继续下一轮;没有 tool_calls 说明 LLM 已经给出最终答案,直接 return。上限 10 是安全兜底,防止工具持续报错时无限循环——正常路径根本跑不到 10 次。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// 外层:对话轮次循环(main 函数里)
for {
handleUserMessage(ctx, client, &messages, input)
}

// 内层:单条消息的 Agent Loop
func handleUserMessage(...) {
for i := 0; i < 10; i++ {  // 上限 10 次,安全兜底
response, _ := client.Chat(ctx, *messages, tools)
*messages = append(*messages, response)

if len(response.ToolCalls) == 0 {
fmt.Printf("AI: %s\n\n", response.Content)
return  // 无工具调用 = 最终答案,退出
}

// 执行工具,把结果追加进 messages,继续下一轮
for _, tc := range response.ToolCalls {
result := calculator(tc.Function.Arguments)
*messages = append(*messages, Message{Role: "tool", Content: result})
}
}
fmt.Println("超过最大轮次")  // 兜底,正常不会触发
}

v2: 多工具系统 (410行)

问题:LLM 只会”说”,不会”干”

v1 的 Agent 只有一个计算器——LLM 可以推理、可以规划,但没有办法真正操作文件、执行命令、读取外部数据。它的能力边界就是它的上下文窗口,干不了任何需要副作用的事。

v2 的思路:引入工具系统,让 LLM 通过结构化的 Function Call 驱动真实操作。抽出统一的 ExecuteTool 路由层——新增工具只改 tools.go,Agent Loop 完全不动。

工具路由接口 (tools.go)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

func ExecuteTool(toolName string, arguments string) string {
switch toolName {
case "calculator":
var args struct {
Expression string `json:"expression"`
}
json.Unmarshal([]byte(arguments), &args)
return calculator(args.Expression)

case "read_file":
var args struct {
Path string `json:"path"`
}
json.Unmarshal([]byte(arguments), &args)
return readFile(args.Path)

case "write_file":
var args struct {
Path    string `json:"path"`
Content string `json:"content"`
}
json.Unmarshal([]byte(arguments), &args)
return writeFile(args.Path, args.Content)

case "edit_file":
var args struct {
Path    string `json:"path"`
OldText string `json:"old_text"`
NewText string `json:"new_text"`
}
json.Unmarshal([]byte(arguments), &args)
return editFile(args.Path, args.OldText, args.NewText)

case "bash":
var args struct {
Command string `json:"command"`
}
json.Unmarshal([]byte(arguments), &args)
return runBash(args.Command)

default:
return fmt.Sprintf("未知工具: %s", toolName)
}
}

关键特性:统一的 switch 路由,每个工具独立解析 JSON 参数,返回字符串结果。支持 5 种工具:计算器、文件读写、编辑、命令执行。

两个最重要的工具:bash 与 edit_file

有了 bash,Agent 拥有了和人类工程师几乎等价的操作能力——编译、运行测试、调用 CLI 工具、查询系统状态,任何能在终端里做的事它都能做。这是从”玩具 Agent”到”能干活的 Agent”的分水岭。

1
2
3
4
5
6
7
8

func runBash(command string) string {
cmd := exec.Command("bash", "-c", command)
output, err := cmd.CombinedOutput()
if err != nil {
return fmt.Sprintf("执行失败: %v\n输出: %s", err, string(output))
}
return string(output)
}

既然有了 bash,为什么还要单独提供 edit_file?直接让 Agent 用 sed 或 echo >> 改文件不行吗?

实践中不行。LLM 生成的 shell 转义极不可靠——多行内容、特殊字符、引号嵌套,稍有偏差就静默写错甚至清空文件,而且错误往往难以复现。edit_file 把”找到原文、替换为新文”抽象成一个原子操作,参数是结构化的 JSON 字符串而不是需要转义的 shell 命令,LLM 生成起来可靠得多。本质上是给 LLM 设计适合它使用的接口,而不是把人类用的工具直接暴露出去。

1
2
3
4
5
6
7
8
9

func editFile(path, oldText, newText string) string {
content, _ := os.ReadFile(path)
if !strings.Contains(string(content), oldText) {
return fmt.Sprintf("错误:在文件中找不到指定的文本")  // 明确报错,不静默失败
}
newContent := strings.Replace(string(content), oldText, newText, 1)
os.WriteFile(path, []byte(newContent), 0644)
return fmt.Sprintf("成功编辑文件: %s", path)
}

注意 strings.Contains 的前置检查——找不到原文直接报错,而不是什么都不做返回成功。这对 Agent 很重要:模糊失败比明确报错更难恢复,LLM 看到错误信息才能在下一轮修正。

集成到 Agent Loop (main.go)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// v1: 硬编码 calculator
// result := calculator(args.Expression)

// v2: 通用工具路由 ⭐
for _, tc := range response.ToolCalls {
fmt.Printf("[调用工具: %s]\n", tc.Function.Name)
fmt.Printf("[参数: %s]\n", tc.Function.Arguments)

// ⭐ 关键变化:统一调用 ExecuteTool,不再硬编码工具名
result := ExecuteTool(tc.Function.Name, tc.Function.Arguments)
fmt.Printf("[工具结果: %s]\n", result)

*messages = append(*messages, Message{
Role:    "tool",
Content: result,
// ...
})
}

核心变化:Agent Loop 本身几乎不变,只是把 calculator(args.Expression) 替换为 ExecuteTool(toolName, arguments)。这实现了开闭原则:新增工具只需修改 tools.go,main.go 无需改动。

v3: 权限系统 (607行)

问题:Agent 拿到了 bash,但没有任何约束

v2 给了 Agent bash 和文件写入能力,但这意味着一条错误的指令就能删文件、跑危险命令。权限系统要解决的核心问题是:Agent 应该在什么情况下可以自主行动,什么情况下必须先问人。

v3 定义了 5 种权限模式,覆盖从”完全信任”到”完全只读”的整个光谱:

另外还有一层路径检查:所有文件操作必须在指定 workspace 目录内,filepath.Rel 检测到 .. 路径穿越直接拒绝。这是最基本的沙箱隔离。

这是简化版本。生产级权限系统会复杂得多:细化到单个工具粒度的白名单、操作审计日志、会话级权限动态升降级、人工审批工作流……我们这里的 5 模式分层已经能覆盖大多数教学和原型场景,但如果是面向真实用户的 Agent,权限设计本身会是一个独立的工程课题。

权限检查逻辑 (permission.go)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

func (p *Permission) Check(opType OperationType, toolName string, details string) (bool, string) {
switch p.Mode {
case ModeReadOnly:
if opType == OpSafe || opType == OpRead {
return true, ""
}
return false, fmt.Sprintf("权限拒绝:当前为只读模式,不允许 %s 操作", opType)

case ModeAskOnWrite:
if opType == OpSafe || opType == OpRead {
return true, ""
}
return p.askUser(toolName, details)

case ModeAutoWrite:
if opType == OpExecute {
return p.askUser(toolName, details)
}
return true, ""

case ModeAllowAll:
return true, ""

case ModePlan:
if opType == OpSafe || opType == OpRead {
return true, ""
}
return false, fmt.Sprintf("权限拒绝:计划模式禁止 %s 操作", opType)

default:
return false, "未知权限模式"
}
}

核心机制:策略模式,5 种模式分别对应不同安全等级。ModeAskOnWrite 需交互确认,ModePlan 完全禁止修改。返回 (bool, string) 元组:布尔值表示是否允许,字符串为拒绝理由。

集成到 Agent Loop

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// Agent Loop 代码与 v2 完全相同!权限检查在工具函数内部透明处理

// tools.go - 以 writeFile 为例
func writeFile(path, content string) string {
// ⭐ 步骤1:检查路径是否在工作区内
if err := globalPermission.CheckPath(path); err != nil {
return fmt.Sprintf("权限错误: %v", err)
}

// ⭐ 步骤2:根据权限模式检查是否允许写操作
allowed, reason := globalPermission.Check(
OpWrite,
"write_file",
fmt.Sprintf("写入文件: %s (内容长度: %d 字节)", path, len(content)),
)
if !allowed {
return reason  // 返回拒绝原因,如 "权限拒绝:只读模式"
}

// ⭐ 步骤3:通过检查后,执行实际操作
err := os.WriteFile(path, []byte(content), 0644)
// ...
}

设计亮点:权限检查对 Agent Loop 完全透明。Loop 调用 ExecuteTool(),工具内部自行处理权限,被拒绝时返回错误信息而非执行。这是职责分离的典范。

v4: Todo + Plan Mode (1119行)

问题:多步骤任务里 LLM 容易迷失

v3 的 Agent 面对复杂任务时,往往走几步就忘了目标,或者反复做同样的事。根本原因是:LLM 没有跨轮次的持久记忆,每轮对话只能靠 context 里的历史消息推断”我做到哪了”——历史越长越贵,越短越容易失忆。

v4 的思路:引入 todo 工具把任务状态外化到结构化列表,再通过 System Prompt 和提醒注入告诉 LLM 如何使用它。

1. Plan Mode 的起点:System Prompt 注入 (main.go)

v3 的 plan_mode 只是权限层的拦截——写操作会被拒绝,但 LLM 自己不知道它处于”规划模式”,只会看到一堆权限错误然后困惑地重试。v4 补上这个缺口:启动时根据当前模式动态构建 System Prompt,把规划流程写进 LLM 的行为指令。权限拦截是”墙”,Prompt 是”路牌”——告诉 LLM 应该怎么走,而不只是哪里不能去。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// main.go — 根据模式动态构建 system prompt
basePrompt := `你是一个助手,可以使用工具:calculator、read_file、write_file、edit_file、bash、todo。
重要:对于复杂任务,使用 todo 工具进行任务分解和进度跟踪:
1. 收到复杂任务时,先用 todo add 添加子任务
2. 开始任务前,用 todo start 标记
3. 完成任务后,用 todo complete 标记`

var systemPrompt string
if mode == ModePlan {
systemPrompt = basePrompt + `

特别注意 - Plan Mode(计划模式):
Plan mode 已激活。你必须遵循以下三阶段流程:

重要约束:只能使用 calculator、read_file、todo
禁止使用:write_file、edit_file、bash

Phase 1 - 理解需求:使用 read_file 阅读相关代码,有疑问直接提问,不要猜测
Phase 2 - 任务分解:用 todo add 添加子任务,要求具体明确、原子化、可验证
  ✅ "在 snake.html 中创建 canvas 元素,设置 id='gameCanvas',宽 800px 高 600px"
  ❌ "创建游戏界面"(太笼统)
Phase 3 - 向用户确认:说明任务数和思路,告知使用 /execute 执行,等待确认`
} else {
systemPrompt = basePrompt
}

messages := []Message{
{Role: "system", Content: systemPrompt},  // ⭐ 运行时注入
}

2. 为什么需要 todo 工具?

Prompt 告诉 LLM”先制定计划”,但有一个根本问题:LLM 没有跨轮次的持久记忆。每次调用都只能看到 messages 里的内容——如果计划只存在于某条 assistant 消息的文字里,随着对话推进它会被”淹没”,LLM 很容易遗忘或跳过还没完成的任务。

解决方案是把”记住任务”这件事变成一个工具调用行为,而不是依赖 LLM 的上下文注意力。LLM 主动调用 todo add 把任务写入外部状态,调用 todo start/complete 更新进度——状态由 Go 程序维护,不会消失,还可以在需要时重新注入回 messages。

3. Todo 管理器 (todo.go)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

type TodoManager struct {
Items               []TodoItem
NextID              int
RoundsSinceLastTodo int  // 追踪多少轮未用 todo 工具
}

func (tm *TodoManager) AddItem(description string) TodoItem {
item := TodoItem{ID: tm.NextID, Description: description, Status: "pending"}
tm.Items = append(tm.Items, item)
tm.NextID++
tm.RoundsSinceLastTodo = 0  // 重置计数
return item
}

// pending → doing → done 三阶段流转
func (tm *TodoManager) StartItem(id int) error { ... }
func (tm *TodoManager) CompleteItem(id int) error { ... }

状态完全在 Go 侧维护,LLM 通过工具调用读写,不依赖上下文记忆。

4. 提醒注入到 Agent Loop (main.go) ⭐ 核心变化

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// v4 是唯一真正修改 Agent Loop 的版本!

for _, tc := range response.ToolCalls {
result := ExecuteTool(tc.Function.Name, tc.Function.Arguments)

// ⭐ 如果 3 轮未使用 todo 工具,把待办状态注入到工具结果里
// LLM 下一轮会读到它,从而想起来更新任务进度
if globalTodoManager.ShouldRemind() && tc.Function.Name != "todo" {
result += globalTodoManager.GetReminder()
}

*messages = append(*messages, Message{Role: "tool", Content: result, ...})
}
globalTodoManager.IncrementRound()

注入的内容是什么?就是下面这段拼出来的纯文本,追加在工具结果末尾,LLM 读 tool message 时会自然看到它:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

func (tm *TodoManager) ShouldRemind() bool {
return tm.RoundsSinceLastTodo >= 3 && len(tm.Items) > 0
}

func (tm *TodoManager) GetReminder() string {
hasPending, hasDoing := false, false
for _, item := range tm.Items {
if item.Status == "pending" { hasPending = true }
if item.Status == "doing"   { hasDoing = true }
}

var sb strings.Builder
sb.WriteString("\n🔔 待办提醒:\n")
if hasDoing   { sb.WriteString("  有任务正在进行中,记得更新状态\n") }
if hasPending { sb.WriteString("  有待处理的任务,记得开始执行\n") }
sb.WriteString("  使用 todo 工具查看完整列表\n")
return sb.String()
}

提醒注入是闭环的最后一环:Prompt 建立初始行为 → todo 工具外化状态 → 提醒注入在 LLM 走神时把状态送回它的视野。三者缺一不可——只有 Prompt 容易遗忘,只有 todo 工具没有提醒 LLM 会忽视,只有提醒没有工具则状态无处存放。

v5: Skill 系统 (1341行)

问题:System Prompt 的扩展瓶颈

随着 Agent 能力扩展,一个自然的冲动是把更多知识塞进 System Prompt——“如何处理 PDF”、”代码审查标准”、”数据库操作规范”。但这条路走不远:每次对话都要发送全部内容,大量 token 花在用不到的知识上;更根本的是,context window 有硬上限,知识越多越快撞墙。

v5 的思路:把专项能力写成独立的 SKILL.md 文件,让 LLM 自己决定什么时候加载什么技能,而不是由我们预判塞满。

SKILL.md 格式

每个技能是一个目录下的 SKILL.md,YAML frontmatter 存元数据,分隔符后是完整内容:

1
2
3
4
5
6
7
8
9
10
11

---
name: code-review
description: Review code quality, style, and best practices
---

# Code Review Skill

### Capabilities
1. Analyze code for bugs and logic errors
2. Review naming conventions and readability
...

格式刻意简单:frontmatter 只需 name 和 description 两个字段,正文是普通 Markdown。

第一步:启动时只扫描元数据

Agent 启动时,scanSkills() 遍历 skills/ 目录,对每个 SKILL.md 只读 frontmatter,不读正文:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

func (sm *SkillManager) scanSkills() {
entries, _ := os.ReadDir(sm.SkillsDir)
for _, entry := range entries {
if !entry.IsDir() {
continue
}
skillPath := filepath.Join(sm.SkillsDir, entry.Name(), "SKILL.md")
if _, err := os.Stat(skillPath); err == nil {
metadata, err := sm.parseSkillMetadata(skillPath)
if err != nil {
continue
}
sm.AvailableSkills[entry.Name()] = &Skill{Metadata: metadata, Loaded: false}
}
}
}

func (sm *SkillManager) parseSkillMetadata(skillPath string) (SkillMetadata, error) {
content, _ := os.ReadFile(skillPath)
text := string(content)
// text[4:] 跳过开头的 "---\n"
parts := strings.SplitN(text[4:], "\n---\n", 2)
// parts[0] 是 YAML frontmatter,parts[1] 是正文(不读)
// 手动解析 name: / description: 两行
...
}

parseSkillMetadata 解析到 \n---\n 就停下,正文根本不进内存。AvailableSkills 里存的只是名字和一句描述。

第二步:把元数据摘要注入 System Prompt

LLM 需要知道”有哪些技能可以用”,但不需要知道细节。GetAvailableSkillsSummary() 把元数据格式化成几行文字,拼进 system prompt:

1
2
3
4
5
6
7
8
9
10
11

// main.go
basePrompt := `你是一个助手,可以使用工具:...

` + globalSkillManager.GetAvailableSkillsSummary() + `
...`

// GetAvailableSkillsSummary() 输出示例:
// 可用技能:
//   - pdf: Process and extract information from PDF files [未加载]
//   - code-review: Review code quality, style, and best practices [未加载]
// 使用 load_skill 工具加载完整技能内容

每次对话多出的 token 消耗只有这几行摘要,而不是所有技能的完整文档。

第三步:LLM 按需调用 load_skill

当 LLM 判断需要某个技能时,调用 load_skill 工具。LoadSkill() 这时才读完整文件,分割出正文,返回内容:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

func (sm *SkillManager) LoadSkill(skillName string) (string, error) {
skill, exists := sm.AvailableSkills[skillName]
if !exists {
return "", fmt.Errorf("技能不存在: %s", skillName)
}
if skill.Loaded {
return fmt.Sprintf("技能 '%s' 已经加载", skillName), nil  // 幂等
}

content, _ := os.ReadFile(filepath.Join(sm.SkillsDir, skillName, "SKILL.md"))
text := string(content)
parts := strings.SplitN(text[4:], "\n---\n", 2)

skill.Content = parts[1]  // 只取正文,去掉 frontmatter
skill.Loaded = true
sm.LoadedSkills[skillName] = skill

return fmt.Sprintf("✅ 技能 '%s' 已加载\n\n%s", skillName, skill.Content), nil
}

返回值直接作为工具结果追加进 messages,技能内容就此进入对话上下文——LLM 下一轮就能用上。注意幂等检查:重复加载直接返回,不会重复注入。

Agent Loop 完全透明

v5 对 Agent Loop 本身没有任何改动。load_skill 只是 ExecuteTool 里新增的一个 case:

1
2
3
4

// tools.go - ExecuteTool 新增一个分支,仅此而已
if toolName == "load_skill" {
return loadSkillTool(arguments)
}

Loop 不感知”技能”的存在,只是照常把工具返回值追加进 messages。技能内容经由这条普通路径自然流入上下文,不需要任何特殊协议。新增技能也不需要改任何代码——放一个目录进去,重启后自动被扫描到。

v6: 上下文压缩 (1590行)

问题:对话越长,成本越高,直到崩溃

LLM 的 API 调用按 token 计费,而且每次调用都要发送完整的历史消息。随着对话轮次增加,token 消耗线性增长——一个长任务里 bash 命令的输出、文件内容的读取结果会迅速撑大上下文。更根本的问题是 context window 有硬上限,超出直接报错,对话无法继续。

v6 引入 ContextManager 统一管理所有消息的读写。Agent Loop 里所有 *messages 的直接操作,全部改成走 globalContextManager.AddMessage() 和 globalContextManager.GetMessages(),压缩逻辑在这个统一出入口里自然嵌入。

策略一:CompressMicro(每轮自动、零成本)

GetMessages() 是 messages 流向 LLM 的唯一出口,每次调用都先触发 CompressMicro。它扫描所有 role 为 tool 的消息,只保留最近 KeepRecentRounds 条,把更早的替换成占位符,零 API 调用静默执行:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

func (cm *ContextManager) GetMessages() []Message {
cm.CompressMicro()
return cm.Messages
}

func (cm *ContextManager) CompressMicro() {
toolIndices := []int{}
for i := len(cm.Messages) - 1; i >= 0; i-- {
if cm.Messages[i].Role == "tool" {
toolIndices = append([]int{i}, toolIndices...)
}
}
if len(toolIndices) <= cm.KeepRecentRounds {
return
}
for _, idx := range toolIndices[:len(toolIndices)-cm.KeepRecentRounds] {
msg := &cm.Messages[idx]
if !strings.HasPrefix(msg.Content, "[已压缩的工具结果]") {
msg.Content = "[已压缩的工具结果]"
}
}
}

代价是彻底丢失历史工具输出的细节——对 LLM 而言,那些工具调用”发生过”但结果已不可见。Micro 只截断工具结果,整体消息数量不减少,对话仍会持续增长。

策略二:CompressAuto(超限触发、保留语义)

当 NeedsCompression() 检测到 token 估算超过阈值(MaxTokens × CompressionRatio,默认 8192 × 0.9),Agent Loop 在每次 Chat 前自动触发;用户也可随时 /compact 手动触发。核心是把待压缩的历史段用一次独立的 LLM 调用浓缩成摘要,再替换原始消息:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

func (cm *ContextManager) CompressAuto(ctx context.Context, client *GLMClient) error {
compressEndIdx := len(cm.Messages) - cm.KeepRecentRounds*2
toSummarize := cm.Messages[systemMsgIdx+1 : compressEndIdx]

response, _ := client.Chat(ctx, []Message{
{Role: "user", Content: buildSummaryPrompt(toSummarize)},
}, nil)

cm.Messages = []Message{
cm.Messages[systemMsgIdx],                                       // 保留 system prompt
{Role: "assistant", Content: "📋 **对话摘要**\n\n" + response.Content}, // 摘要替换历史
cm.Messages[compressEndIdx:]...,                                 // 保留最近 N 轮
}
return nil
}

摘要的质量取决于提示词。buildSummaryPrompt 把历史消息序列化后,要求 LLM 输出结构化的两段:

1
2
3
4
5
6
7
8
9
10
11
12

sb.WriteString("输出格式:\n")
sb.WriteString("<analysis>\n对当前状态的深入分析(2-3 句)\n</analysis>\n")
sb.WriteString("<summary>\n")
sb.WriteString("1. 初始用户请求和高层目标\n")
sb.WriteString("2. 已完成的关键步骤\n")
sb.WriteString("3. 当前工作状态\n")
sb.WriteString("4. 待完成的任务(如有)\n")
sb.WriteString("5. 重要的技术决策和原因\n")
sb.WriteString("6. 相关文件路径\n")
sb.WriteString("7. 遇到的错误和解决方案(如有)\n")
sb.WriteString("8. 下一步行动建议\n")
sb.WriteString("</summary>\n")

结构化输出让 LLM 在后续轮次能快速定位上下文,而不是从一段流水叙述里自己提取。这也是为什么摘要以 assistant 角色注入——对 LLM 而言,这就是它”自己之前写下的记录”,而不是外部注入的元数据。

v7~vN:还能走多远?

我们用 ~1600 行 Go 代码,从零实现了一个具备工具调用、权限控制、任务规划、技能加载和上下文压缩的 Agent。但这只是起点。现实中的 Agent 系统还有很多值得继续演进的方向:

待完善的能力

但核心思想其实很简单

回头看整个演进,Agent 的本质始终是同一个 for 循环:调用 LLM → 执行工具 → 把结果塞回上下文 → 重复。所有复杂性都是在这个循环的外围加约束、加状态、加策略。

以子 Agent 为例——听起来很复杂,实现思路其实直接:把”启动子 Agent”做成一个普通工具,主 Agent 通过 Function Call 调用它;工具实现里用 Go 的 goroutine 跑一个完整的 Agent Loop,完成后把执行摘要作为 tool result 返回;主 Agent 拿到摘要继续规划下一步。整个机制复用了我们已有的工具系统、上下文压缩和 todo 状态管理,没有引入任何新的架构概念。

多 Session、Memory 也是同理:Session 是上下文的隔离单元,Memory 是跨 Session 的持久化 Skill,它们都能用已有的抽象自然延伸出来。

真正的难点:Harness

把 Agent Loop 写出来只需要几十行。让 Agent 真正把工作做好,才是难的部分——这就是 Harness 的概念:围绕 Agent 构建的一整套”脚手架”,决定了 LLM 能看到什么、能做什么、做错了怎么纠正。

我们的实现其实已经包含了 Harness 的雏形:

但生产级的 Harness 远不止这些——评估与回滚(LLM 做错了怎么恢复)、可观测性(每一步的 token 消耗、工具调用链路)、沙箱隔离(bash 执行的安全边界)、重试与降级……每一项都是独立的工程课题。

从这个角度看,Agent 本身的代码是最简单的部分。Harness 才是让 Agent 真正可用的工程核心。

这也是为什么理解 Agent 的最好方式,是自己从零写一遍——当你亲手把 for 循环、工具路由、权限检查、提示词注入这些拼在一起,”Agent”就从一个模糊的概念变成了一组具体的设计决策。

PS：2025 年 10 月 30 日，问题已定位，BMC 会在主板的所有网口周期发送数据包（探测包？），如果 2.5Gbps 网口（非管理口）未接线，会导致其内核持续内存泄露，直至 OOM。解决办法是在 BMC 里禁用该网口。

PS：截止 2025 年 10 月 8 日，H12D BMC 模块存在内存泄露的 BUG，导致每 14～15 天就会挂死（IPMI 相关进程都被杀死了），管理界面、IPMI、风扇控制全部失灵，只能拔电源冷重启，暂不建议购买。

用了很久 NAS 了，简单记录一下 NAS 方案演进。

初探 NAS（小而美）

  刚玩 NAS 的时候，对 NAS 的理解就是稳定 7 x 24 开机的网络存储平台。硬件方面采用 DQ77KB + i5 3570S + 蜗牛星际方案（DQ77KB + 矿渣机箱翻车记）。软件平台直接使用 Windows Server 开启 SMB，同时用 QBittorrent RSS 自动下载，配合 Jellyfin 进行刮削。

  整体使用起来还是很舒服的，可以称作小而美。DQ77KB 自带 AMT（IPMI）， 配置完成后可以扔在角落吃灰，也奠定了后续演进一定要有带外管理便于远程摸鱼救砖的方针。

转向服务器平台（换汤不换药）

  随着库存数据越来越多，i5 3570S 性能瓶颈逐渐出现，最主要的是编解码性能，使用 Jellyfin 观看高清视频时拖拽会卡顿。同时因为矿盘逐渐增加，盘位不够，因此换成了 R730XD 12 盘位（E5 2680v4 x 2）。

  服务器配齐了前后 12 + 2 盘，H730 阵列卡，服务器内部看起来非常舒心。

  为什么说是换汤不换药呢，是因为这个阶段软件并没有发生变化，只是单纯的将系统迁移到新平台，解决了 Jellyfin 观看视频卡顿痛点。尴尬的是后面买了 AppleTV 使用 infuse 播放直接把转码问题给消灭了。总得来说，最初我对 R730XD 还是很满意的。其他用户反馈的噪音大的问题，在 4~6 盘情况下，通过更换静音风扇与配合 IPMI 调速到 20%，温度和噪音都是可接受的，隔一扇门基本无感。

失败的硬阵列尝试（适合自己的才是最好的）

  就这样度过了美好的 3 年，在 R730XD 逐步加盘的过程，问题出现了，每次迁移数据比较麻烦，需要硬盘一次次的拷贝，并且需要对盘符和路径做复杂处理才能让各种软件不感知变化。我决定一次性购入 8 块 16T MG08 通过 H730 组建硬阵列，毕其功于一役。

  此时的我还是很信任企业级的方案，选择硬阵列也是考虑到硬阵列可以屏蔽底层细节，向上层 Windows 直接虚拟出硬盘，不需要操作系统和软件层面做任何改动，80T 左右的可用空间也足够我较长时间使用。而如果使用在软阵列里性能相对较好比较靠谱的 TrueNAS 方案，就需要将物理机上的 Windows 虚拟化，作为一个懒人自然不予考虑。

  理想是美好的，现实是骨感的。当插上所有硬盘，开启阵列的创建之后，痛苦开始了。由于硬阵列是基于块和条带的，因此创建阵列完毕一定需要初始化（填 0 和计算奇偶校验）。此时硬盘会持续写入，简单计算可知 16T / 200MB/s = 22 小时。由于机架服务器的设计，进风几乎都来自前置硬盘位，因此插满硬盘后，会严重影响进风。这高速写入的 22 小时，风扇需要 50%+ 才能压制住机器，即使如此硬盘也保持在了 50℃+，吸尾气的 CPU 分分钟突破 90℃，此时噪音和热量根本无法忍受！！！

  在组阵列，睡前关机，睡醒开机继续组阵列后，以及多次修改参数，尝试提升速度重新开始后，我终于崩溃了。将服务器挂到闲鱼上以 1200 的价格卖了出去（购入价 2000）。这里用我的血泪告诫大家，没有机柜和独立的设备间还是不要玩机架服务器了~当然我相信，机架服务器永远是 NAS 的最终的归宿，希望有一天能够把公司的星星海搬回家。

取其精华去其糟粕

  痛定思痛之后，明白了我的需求从来没有变过，那就是“在角落吃灰”，它在这个物理世界需要足够安静和稳定。基于这个目的，就开始了硬件平台的选择。正巧最近 EPYC 7D12 大船到岸只需要 240，32 核 64 线程（1.10GHz ~ 3.00GHz），TDP 80W 简直就是 NAS 佬的梦中情 U。ZEN2 架构性能毋庸置疑，同时功耗发热足够低，无需像使用 E5 双路时修改功耗策略。

  确定了 CPU 就要配套主板了，板 U 守恒定律名不虚传，二手的超微 H12SSL 以及华硕技嘉的主板价格都突破了 3000， 相较年初翻了一翻，说实话不是很好的选择了，因此就选择了寨板大厂华南金牌 H12D-8D，带有 BMC 模组可以满足基本的使用，同时有 3 个 8643 接口以及 4 个 SATA，满足了 16 盘的需求，不需要额外购买阵列卡。

  剩下的最重要的就是选择机箱了，在乔思伯 N5 和梵隆 12 盘位中纠结了一段时间，考虑到无论是全高还是半高的梵隆散热器都限高，暴力风扇的阴影还笼罩在心头，因此还是选择了可以安装 12cm/14cm 风扇的乔思伯。需要注意的是两点，一是乔思伯的背板是 SATA 的，需要购买 8643 转 SATA。二是乔思伯自带的三把风扇是 3Pin 非 PWM 调速，因此噪音会比较大，建议换 PWM 调速风扇。

  购买/装机清单如下：

• CPU：EPYC 7D12 ¥258.00
• 主板：华南金牌 H12D-8D BMC ¥2307.99
• 内存：三星 DDR4 64Gx4 ¥1467.15
• 散热器：利民 TA120EX TR4 SP3 ¥208.57
• 机箱风扇：利民 TL-G12Bx3 ¥68.36
• 电源：长城 N8 850W 金牌 ¥565.03
• 机箱：乔思伯 N5 ¥1140.40
• 固态 1（SLOG）：Intel 傲腾 900P 280G ¥534.00
• 固态 2（PVE）：Samsung PM981a 512GB ¥0.00 (存货)
• 固态 3 (缓存)：Intel S3520 800GB ¥0.00 (存货)
• 总计：¥6549.50

  安装过程是枯燥的，也没有太多值得说到的，箱子做工对于这个价位中规中矩，建议从下往上安装，把硬盘背板先装好，我的这个长城 N8 电源的 SATA 供电在接完背板之后就无法送到上层安装 2.5 寸 SSD 了，因此 S3520 扔在了下层。同时由于 7D12 内存缺通道（4 通道）所以需要多尝试尝试，最终我的这块 U 需要将内存安装在最外侧的插槽才能识别全部 256GB 内存。

  这里可以发现，由于主板 CPU 插槽设计的朝向，CPU 风扇（侧吹）和机箱风扇（后吹）风向不是一致的，可能会影响风道，如果用服务器 2U 暴力风扇应该是一致的。个人因为比较懒，且 7D12 功耗不高，就不愿意再将机箱风扇调整到右侧了。同时需要提醒的是华南 H12D 的主板风扇只有两个风扇接口支持温控调速（我图上 CPU 和上层风扇所接的右上角接口）。用起来会发觉风扇很吵，调了很久主板 PWM 调速不见效果，仔细研究后才发现下层的风扇接的主板接口是 ipmi 手动调速的，并不支持温控（服务器好的不学，净学些坏的）。不过手动调整转速到 1000 RPM后，即使机箱放在床边也几乎无感了。

1
2

# 调速到 66%（0x42%），利民风扇全速 1500RPM
ipmitool -I lanplus -H 172.17.0.199 -U admin -P admin raw 0x0e 0x65 0 0x42

  这是安装完成的效果，机箱很大可能图片上看不出来，橡胶把手凑合能用，真想拔出硬盘的时候会很担心拔断，比硬盘托架肯定差远了，不过确实是 12 盘位里比较好看的了：

  忙完了硬件就是忙软件层面了，因为放弃了灵活性较差的硬阵列，所以这一代软件方案底层采用 PVE 虚拟化平台， 将之前物理硬盘安装的 Windows Server 进行虚拟化，同时运行 TrueNAS。并将全部 SATA 控制器以及 PCIE 的傲腾 900P 直通给 TrueNAS。

  然后就是繁琐的软阵列创建和数据迁移工作，这里需要注意 TrueNAS 在 Scale 版本移除了 WEB 界面的数据导入以及内核里的 NTFS 支持，因此我是在 Core 版本将原始的 NTFS 硬盘数据完成迁移后再升级到 Scale 的。

  总结一下，当前存储方案是，8 块 MG08 组成 RADIZ2，傲腾 900P 分出 32GB 分区作为阵列的 SLOG。RAIDZ2 使用 SMB 共享给 Window Server，实测 Jellyfin（不能运行在服务模式）和 QBittorrent 等软件都能正常运行。同时 S3520 创建 ZVOL 分区 iSCSI 挂载给 Windows Server 做下载缓存盘，减少阵列读写（夜间持续咯哒咯哒还是有点小烦）。

  至此我的第三代 NAS 也完成了软硬件升级（PS：买的 Mellanox CX4 25Gbps 网卡还在路上，不过应该对 NAS 整体架构没有太大影响）~

小更新

  CX4 网卡到手了，SR-IOV 直通 TrueNAS 和 Windows 相较 VirtIO 性能在网络传输性能上确实有大幅度提升，贴一下 Windows 远程读写 TrueNAS SMB 性能吧，性能够用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

┌─────────┐      ┌─────────┐               
│         │      │         │               
│  Modem  │      │   NAS   │               
│         │      │         │               
└────┬────┘      └────┬────┘               
     │                │                    
     │                │                    
     │     Switch     │                    
┌────┴───┌────────┌───┴────┌────────┐      
│  Port1 │  Port2 │  Port3 │  Port4 │......
│        │        │        │        │      
└────────└───┬────└────────└────────┘      
             │                             
             │                             
             │                             
             │                             
         ┌───┴────┐      ┌────────┐        
         │        │      │        │        
         │ Router ├──────┤   AP   │        
         │        │      │        │        
         └────────┘      └────────┘        

  交换机 VLAN 配置如图所示：

1
2
3
4
5
6
7
8
9
10
11

VLAN    VLAN描述    成员端口    Tagged端口    Untagged端口
1       LAN        2-6        2-6
2       WAN        1-2        2            1

端口     PVID
端口1    2
端口2    1
端口3    1
端口4    1
端口5    1
端口6    1

  关于 tagged untagged PVID 的解释，交换机的帮助说的比网上的介绍清楚很多，这里粘贴一下：

1. Untagged 将此端口上的流量的出口规则设置为 untagged。在发送数据包之前，交换机会丢弃 tag 头。
2. Tagged 将此端口上的流量的出口规则设置为 tagged。在发送数据包之前，交换机会添加 tag 头。
3. PVID(端口 VLAN ID)是端口缺省 VID。当端口接收到一个 untagged 包，它将给这个包添加一个带有端口 PVID 的 VLAN tag 并转发该数据包。

  软路由的 Openwrt 配置很简单， LUCI 界面直接新增一个接口 eth0.2 虚拟口作为 WAN 口，原来的物理口 eth0 加入到 LAN。

  简单的来说通过配置端口 1 和端口 2 被加入了 VLAN2，光猫的untagged包进入端口 1 后会被打上 VLAN2 标签（PVID2），被转发到端口 2 送给软路由 WAN 口 eth0.2 用于拨号上网。软路由的 WAN 口（eth0.2） 回程 VLAN2 数据包会在从端口 1 发往光猫时去除 VLAN 标签。这样就通过 VLAN2 完成了拨号功能。

  对于软路由 LAN（eth0） 无标签数据包进入端口 2 后会被打上 VLAN1 标签（PVID1），转发给同在 VLAN1 的端口 3～6。数据包在从端口 3～6 发送给设备（NAS），也会去除 VLAN 标签，反之同理，这样就完成交换机下的 LAN 设备与软路由下其它 LAN 设备互通。

　　随后突然想起 ebpf 的 XDP Hook 是对 ingress 生效的，如果想做 egress 则得使用 TC Hook。既然如此， Linux 的 TC 工具是不是已经原生支持了我的小需求呢，之前对 TC 工具的使用局限在 netem 和 tbf 模块，也就是弱网模拟和流控。查阅文档发现 TC 的 Pedit 模块可以很轻松的提供我需要的无状态（Stateless）NAT 能力。

　　在我的场景下需要将 wg0 发出的数据包的 SRC 和 DST 修改成特定的 IP，这里就以匹配 SRC 3.3.3.3 和 DST 4.4.4.4 的数据包并将其修改为 SRC 1.1.1.1 和 DST 2.2.2.2 为例了。

创建队列

　　首先就是创建一个 clsact 队列，这个队列有 ingress 和 egress 两个钩子。

1

$ tc qdisc add dev wg0 clsact

修改数据包

　　随后的命令很直观，指定网卡 wg0 的 egress 方向。flower（flow based traffic control filter）根据 src_ip dst_ip 匹配 ip 数据包，首先通过 pedit action 修改 ip，再使用 csum action 为数据包重新计算 Checksum。

1
2
3
4
5
6
7
8
9

$ tc filter add dev wg0 egress protocol ip \
    flower \
    src_ip 3.3.3.3 \
    dst_ip 4.4.4.4 \
    action pedit ex \
        munge ip src set 1.1.1.1 \
        munge ip dst set 2.2.2.2 \
    pipe \
    action csum ip tcp udp

10 年前一个傻乎乎的高中生，对一切都充满了好奇，写下了第一篇现在看起来是黑历史的文章。
10 年后一个疲倦的大厂社畜，在异乡漂泊，扎不下根，空隙时突然想记下当下，此刻耳机响着的是 《Chasin’ You》。
愿下 10 年还能相见。

　　二〇二二。勿失勿忘。

　　以一个三节点的网络为例：两台路由器 Openwrt 版本分别为 18.06 与 19.04，一台服务器部署了 Ocserv 用于不能直接使用 ZeroTier 设备通过 VPN 接入，网段如下。

1
2
3
4

ZeroTier：10.244.0.0/24
路由器 A（Openwrt）：172.16.0.1/16
路由器 B（Openwrt）：172.17.0.1/16
服务器 C（Ocserv）：192.168.30.0/24

　　关于 ZeroTier 注册和 Ocserv 相关的设置就不赘述了，主要关注 Openwrt 的相关的配置。

安装 ZeroTier

　　安装 ZeroTier 非常简单，使用 ssh 登录路由器，使用包管理器安装即可，使用 LUCI 图形化安装也行，不过下面的配置仍需要在命令行中进行。

1
2

$ opkg update
$ opkg install zerotier

配置 ZeroTier

　　安装完成后，编辑配置文件 vi /etc/config/zerotier，初始配置文件如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

config zerotier sample_config
        option enabled 0

        # persistent configuration folder (for ZT controller mode)
        #option config_path '/etc/zerotier'

        #option port '9993'

        # Generate secret on first start
        option secret 'generate'

        # Join a public network called Earth
        list join '8056c2e21c000001'

　　需要修改的地方只有两处：

1. option enabled 0 将 0 修改为 1。
2. list join '8056c2e21c000001' 将 Earth 网络 id 修改自己的私有网络 id。

　　完成后执行命令启动即可。

1

$ /etc/init.d/zerotier start

　　可以通过命令查看连接到的网络，建议不用着急去 ZeroTier 网页配置 IP，等全部配置完成后再进行统一规划，避免敲错网段导致断网（逃。

1

$ zerotier-cli listnetworks

创建接口与防火墙

　　为了便于配置，我们需要为 ZeroTier 创建的网卡创建一个接口和独立的防火墙，如图所示：
　　创建一个叫 ZeroTier 的接口，绑定 ZeroTier 创建的虚拟网卡。

　　保存后，为 ZeroTier 创建一个专属的防火墙区域，也叫 ZeroTier。

配置防火墙

　　创建完成后，配置 ZeroTier 的防火墙，如图所示：

1. Input、Output、Forward 全部允许。
2. 允许 ZeroTier 转发至 lan。
3. 允许 ZeroTier 转发自 lan。
   

Zerotier 网页配置

　　接着登录 ZeroTier 网站，为我们的设备分配 IP。

1
2
3
4

ZeroTier：10.244.0.0/24
路由器 A（Openwrt）：172.16.0.1/16      10.244.16.1
路由器 B（Openwrt）：172.17.0.1/16      10.244.17.1
服务器 C（Ocserv）：192.168.30.0/24     10.244.30.1

　　接着在网页添加静态路由，如图所示：

测试

　　完成上面的配置后，网络就打通了，无需使用 iptables 进行 NAT。
　　在路由器 B 上执行 ip route 可以看到 ZeroTier 下发的路由表。

1
2
3
4
5

$ ip route
10.244.0.0/16 dev ztyouvscim proto kernel scope link src 10.244.17.1
172.16.0.0/16 via 10.244.16.1 dev ztyouvscim
172.17.0.0/16 dev br-lan proto kernel scope link src 172.17.0.1
192.168.30.0/24 via 10.244.30.1 dev ztyouvscim

　　在路由器 A 上也可以 traceroute B 路由器下的设备，说明我们完成了组网的工作。

参考链接

　　如果对配置看得不是很懂，可以参考下面这篇文章，配图更加详细，防火墙的配置按照本文来即可。

1. Openwrt路由通过Zerotier组网实现异地内网互访

CAA

　　要搞明白这个 bug 得先了解 CAA 是干嘛用的。简单的来说 CA 在签发证书的时候需要检查一下域名的 CAA 记录，如果有自己的话就签发，如果没有就拒绝签发。通过设置 CAA 就可以防止某些人利用其它 CA 的一些漏洞签发证书。比如这次的 let's encrypt，CAA 需要设置成 letsencrypt.org。如果什么都不设，任何 CA 都可以签发证书。

漏洞发现

　　了解了 CAA 就可以来看一看 let's encrypt 论坛上的这个求助。正确情况下检测多个域名 CAA 如果一个域名检测失败，报一次错；多个域名检测失败，报多个不同的错。但实际上 admin.mrhs.hwrsd.org 这个域名报错 99 次。并且 let's encrypt 也的确重复检查了 99 次。

　　也就是说实际上只检测了 admin.mrhs.hwrsd.org 一个域名，其它域名并没有被检测。这样就可以使用一个可以通过检测的域名来让那些那些没有正确设置 CAA 的域名逃过检测。

漏洞代码

　　那问题出在了哪呢，看到这个直白的 pull request 标题就明白了 Pass authzModel by value, not reference。
　　看一下那段处理多个域名的代码。

1
2
3
4
5
6
7
8
9
10
11
12
13

func authzModelMapToPB(m map[string]authzModel) (*sapb.Authorizations, error) {
resp := &sapb.Authorizations{}
for k, v := range m {
// Make a copy of k because it will be reassigned with each loop.
kCopy := k
authzPB, err := modelToAuthzPB(&v)
if err != nil {
return nil, err
}
resp.Authz = append(resp.Authz, &sapb.Authorizations_MapElement{Domain: &kCopy, Authz: authzPB})
}
return resp, nil
}

　　乍一看这段代码看起来都没有什么问题。循环调用 modelToAuthzPB 方法，传入引用 v 获得 authPB。为循环中会被重新分配的 k 创建拷贝。最终将 k 与 authPB 返回走。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

func modelToAuthzPB(am *authzModel) (*corepb.Authorization, error) {
expires := am.Expires.UTC().UnixNano()
id := fmt.Sprintf("%d", am.ID)
status := uintToStatus[am.Status]
pb := &corepb.Authorization{
Id:             &id,
Status:         &status,
Identifier:     &am.IdentifierValue,
RegistrationID: &am.RegistrationID,
Expires:        &expires,
    }
    ...
    return pb, nil
}

　　但问题在于所返回的结构体 pb 内部的元素也是引用，比如这个 &am.IdentifierValue。每次传入的 v 是引用，结构体中的元素也是引用。这就导致 authPB 看起来不是个引用，实际上它的内部还是个引用。循环结束后，authPB 的值都来自于最后一次的 v 的结果。也就是说如果最后一个域名通过了检测，那么之前的域名都会通过检测。

解决方案

　　知道了原因，那解决起来就简单了，第一种方法直接将 modelToAuthzPB 方法从传引用改成传值。第二种方法像 k 一样，为 v 也搞一个 vCopy。而 let's encrypt 选择了第一种方法。

1
2
3
4
5
6
7
8
9
10
11
12
13

func authzModelMapToPB(m map[string]authzModel) (*sapb.Authorizations, error) {
resp := &sapb.Authorizations{}
for k, v := range m {
// Make a copy of k because it will be reassigned with each loop.
kCopy := k
authzPB, err := modelToAuthzPB(v)
if err != nil {
return nil, err
}
resp.Authz = append(resp.Authz, &sapb.Authorizations_MapElement{Domain: &kCopy, Authz: authzPB})
}
return resp, nil
}

　　说实话在我自己的项目里各种 reference 乱飞，多半某天也会像这样吃个亏。

　　思路很简单，服务器验证账号和密码后，将拼接的用户名与过期时间作为 Payload,使用 HMACSHA256 对拼接后的 Payload 进行签名。再与 Base64 编码后的 Payload 进行拼接。token 结构为 SignaturePayload.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// 设置签名 key 与超时时间
const secret = "Secretkey"
const exp = 31536000

// 生成 Token
func EncodeToken(username string) string {
    // 过期时间
    expireTime := time.Now().Unix() + exp
    // 拼接 payload
    data := username + "." + strconv.FormatInt(expireTime, 10)
    // base64 编码
    base64Data := base64.StdEncoding.EncodeToString([]byte(data))
    // 生成签名
mac := hmac.New(sha256.New, []byte(secret))
mac.Write([]byte(data))
    expectedMAC := hex.EncodeToString(mac.Sum(nil))
    // 生成 token
token := expectedMAC + base64Data
return token
}

　　用户之后的访问携带该 token，服务器将 Base64 编码的 Payload 解码，使用 HMACSHA256 签名并与 Signature 部分验证。如果通过验证，判断用户名是否存在和 token 是否过期。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

func VerifyToken(token string, username *string) bool {
    // 提取签名与编码后的 payload
messageMAC := token[:64]
    base64data := token[64:]
    // base64 解码
data, err := base64.StdEncoding.DecodeString(base64data)
if err != nil {
return false
    }
    // 验证签名
mac := hmac.New(sha256.New, []byte(secret))
mac.Write(data)
if messageMAC == hex.EncodeToString(mac.Sum(nil)) {
        // 验证用户名与超时时间
*username = strings.Split(string(data), ".")[0]
expireTime, _ := strconv.ParseInt(strings.Split(string(data), ".")[1], 10, 64)
if controller.HavingUser(*username) && expireTime > time.Now().Unix() {
return true
}
return false
}
return false
}

安装 docker

　　树莓派上使用的是 arch 系的 manjaro，其它系统类似。

1
2
3

sudo pacman -S install docker docker-compose docker-machine
sudo usermod -a -G docker $user
sudo systemctl start docker

创建容器

1
2
3
4

docker pull alpine
docker pull alpine
docker network create --driver=bridge hadoop
docker run -itd --name=master --net=hadoop alpine

安装 hadoop

1
2
3
4
5
6
7
8

docker attach master
apk update
apk add openjdk8 openssh bash ncurses shadow openrc
cd /var
wget http://mirrors.tuna.tsinghua.edu.cn/apache/hadoop/common/hadoop-3.2.1/hadoop-3.2.1.tar.gz
tar xzvf hadoop-3.2.1.tar.gz
mv hadoop-3.2.1 hadoop
rm hadoop-3.2.1.tar.gz

配置环境变量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 修改 /etc/profile
vi /etc/profile
# 添加环境变量
export PATH=/var/hadoop/bin
export JAVA_HOME=/usr/lib/jvm/java-1.8-openjdk
export HADOOP_HOME=/var/hadoop/
export PATH=$PATH:$HADOOP_HOME/bin
export PATH=$PATH:$HADOOP_HOME/sbin
export HADOOP_MAPRED_HOME=$HADOOP_HOME
export HADOOP_COMMON_HOME=$HADOOP_HOME
export HADOOP_HDFS_HOME=$HADOOP_HOME
export YARN_HOME=$HADOOP_HOME
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native
export HADOOP_OPTS="-DJava.library.path=$HADOOP_HOME/lib"
export JAVA_LIBRARY_PATH=$HADOOP_HOME/lib/native:$JAVA_LIBRARY_PATH

1
2
3
4
5
6

# 生效环境变量
source /etc/profile
# 启动 sshd
rc-update add sshd
touch /run/openrc/softlevel
/etc/init.d/sshd start

配置用户组与密钥

1
2
3
4
5
6
7

adduser hadoop
usermod -aG hadoop hadoop
chown hadoop:root -R /var/hadoop
chmod g+rwx -R /var/hadoop
su - hadoop
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

配置 hadoop

配置 hadoop-env.sh

1
2
3
4

# 修改 hadoop-env.sh
vi /var/hadoop/etc/hadoop/hadoop-env.sh 
# 修改 JAVA_HOME
export JAVA_HOME=/usr/lib/jvm/java-1.8-openjdk

配置 core-site.xml

1

vi /var/hadoop/etc/hadoop/core-site.xml

1
2
3
4
5

<!-- <configuration> 标签内添加 -->
<property>
    <name>fs.default.name</name>
    <value>hdfs://localhost:9000</value>
</property>

配置 yarn-site.xml

1

vi /var/hadoop/etc/hadoop/yarn-site.xml

1
2
3
4
5
6
7
8
9

<!-- <configuration> 标签内添加 -->
<property>
    <name>yarn.nodemanager.aux-services</name>
    <value>mapreduce_shuffle</value>
</property>
<property>
    <name>yarn.nodemanager.aux-services.mapreduce.shuffle.class</name>
    <value>org.apache.hadoop.mapred.ShuffleHandler</value>
</property>

配置 mapred-site.xml

1
2

cp /var/hadoop/etc/hadoop/mapred-site.xml.template /var/hadoop/etc/hadoop/mapred-site.xml
vi /var/hadoop/etc/hadoop/mapred-site.xml

1
2
3
4
5

<!-- <configuration> 标签内添加 -->
<property>
    <name>mapreduce.framework.name</name>
    <value>yarn</value>
</property>

配置 hdfs-site.xml

1

vi /var/hadoop/etc/hadoop/hdfs-site.xml

1
2
3
4
5
6
7
8
9
10
11
12
13

<!-- <configuration> 标签内添加 -->
<property>
    <name>dfs.replication</name>
    <value>3</value> 
</property>
<property>
    <name>dfs.namenode.name.dir</name>
    <value> file:/var/hadoop/hadoop_data/hdfs/namenode</value>
</property>
<property>
    <name>dfs.datanode.data.dir</name>
    <value> file:/var/hadoop/hadoop_data/hdfs/datanode</value>
</property>

创建 DataNode

1
2

mkdir -p /var/hadoop/hadoop_data/hdfs/datanode
CRTL P+Q

创建 hadoop 模板镜像

1
2

docker ps -a
docker commit master hadoop-raw

创建配置 data1 容器

1
2

docker run -itd --name=data1 --net=hadoop hadoop-raw
docker attach data1

修改 core-site.xml

1

vi /var/hadoop/etc/hadoop/core-site.xml

1
2

<!-- 修改原值 -->
<value>hdfs://master:9000</value>

修改 yarn-site.xml

1

vi /var/hadoop/etc/hadoop/yarn-site.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<!-- <configuration> 标签内添加 -->
<property>
    <property>
        <name>yarn.resourcemanager.resource-tracker.address</name>
        <value>master:8025</value>
    </property>
    <property>
        <name>yarn.resourcemanager.scheduler.address</name>
        <value>master:8030</value>
    </property>
    <property>
        <name>yarn.resourcemanager.address</name>
        <value>master:8050</value>
    </property>
</property>

修改 mapred-site.xml

1

vi /var/hadoop/etc/hadoop/mapred-site.xml

1
2
3
4
5

<!-- <configuration> 标签内添加 -->
<property>
    <name>mapred.job.tracker</name>
    <value>master:54311</value>
</property>

修改 hdfs-site.xml

1
2

vi /var/hadoop/etc/hadoop/hdfs-site.xml
# 删除namenode所在的<property>标签

更新 hadoop 模板镜像，创建 data2 3 容器

1
2
3

docker commit data hadoop-raw
docker run -itd --name=data2 --net=hadoop hadoop-raw
docker run -itd --name=data3 --net=hadoop hadoop-raw

创建 NameNode

1
2
3

docker attach master
mkdir -p /var/hadoop/hadoop_data/hdfs/namenode
hadoop namenode -format

启动 hadoop 集群

1

start-all.sh

A：刚刚开了一个脑洞，比如 C 里面写了个 scanf 然后开始运行，这个应该算是一个程序运行带来的异常还是 IO 中断。

B：我这么想，C 的 scanf 先系统调用进入内核，然后内核在这个状态等待一个 IO 中断，之后完成系统调用再返回用户态。

C：先是陷入异常 后面可能会有 DMA 传输之类的东西？所以可能还会结合中断处理。

D：感觉中断应该是外部事件，是正在运行的程序所不期望的，但是这个例子里的输入就是正在运行的这个程序所期望的，而且是这个程序内部的函数需要的，应该不算中断？

　　我个人第一反应是键盘产生中断，操作系统处理后供 scanf 读取，scanf 本身没有触发中断和异常机制。于是查询资料的时候找到了 Kernel Stdio Theory 这篇文章，在理解还没到位的情况下，瞎翻译一下。

标准输入/输出原理

什么是标准输入/输出？

　　标准输入输出以及标准错误都是 C 标准库流实现的一部分。流是访问文件、硬件资源、其它进程的读写接口。

　　引用 stdio.h 后，三个流会自动创建并与环境的标准输入输出以及错误流连接。在大部分情况下，进程的标准输出和错误会绑定到打开它的终端上。在 Stdin 没有被重定向情况下，默认的标准输入源是键盘。

　　这些效果由 C 库处理，与底层操作系统交互提供流资源的访问。流资源包含以下属性：

• 读/写
• 文本/二进制
• 缓冲/无缓冲

　　大部分情况，StdOut 默认是有缓冲，StdErr 无缓冲。这样可以让用户立即看到输出到 StdErr 中的数据。缓冲可以是行缓存或完全缓冲。C 标准库的复杂性不是本文的关注点。

　　内核必须提供底层设备的 API 并将它们提供给正在运行的程序。所有程序，为了输入默认将键盘绑定为 StdIn，控制台绑定为 StdOut。

　　由于 C 用于开发 Unix 内核，且 Unix 提供将设备抽象成一般文件的方法。进程可以简单的将设备当作资源流打开，将 StdIO 连接到设备上进行读写。

　　终端是一个经典的例子，来了解 Unix 的 StdIO 如何工作的基本知识。注意，提供这种抽象不一定要通过文件。Windows API 通过函数调用提供这种抽象。实际上程序只有运行在终端下时才会使用 StdIn、StdOut 和 StdErr。对于 GUI 程序 StdIn、StdOut、StdErr 会由开发人员替换成相关 API，如弹窗用于错误和警告。

　　在 Unix 内核中默认的基本输出连接到了用户的终端设备（如 /dev/tty0）。在你的 Unix/Linux 命令提示符中输入 who am i。代表当前终端的标准输出的设备。

　　在微型计算机中没有终端连接到大型主机，因此现代 Linux/Unix 微型计算机只是创建了一个终端设备，并将其连接到内核的标准输出。

　　执行：echo Hello from std Output! >file

　　通过重定向程序的基本输出，将字符串 “Hello from std Output” 打印到名为 file 的文件中。程序获得了 file 的文件句柄作为它的 stdout 设备，并写入文件。

　　返回到之前运行 who am i 或简化成 tty 的终端。将 file 替换成 tty 的输出。我的内核报告的终端是 dev/pts/1。

　　执行：echo Hello from std Output! >/dev/pts/1

　　这次会在终端看到 echo 的输出。这是由于我们把 Stdout 的基本输出重定向回了我们的 Stdout 上。也就是例子中的 dev/pts/1，实际上它与当前用户的标准输出同义。

　　有意思的是，这个文件也充当着 Stdin 设备：读取键盘输入的字符并报告给读取它的程序。

　　Unix cat 命令会读取并输出文件中的内容，键盘输入会被送到程序正在读取的 Stdin。

　　执行：cat /dev/pts/1

　　输入单词和字符并按下回车。输入的字符会被送到 cat 正在读取的 Stdin。按下 enter 表示到达当前输入的行尾，内核停止读取键盘输入，并将这行输入送入当前被 cat 读取的标准输入。cat 认为它正在读取一个普通的文件，并完成工作：将文件内容输出到终端。

　　输入完行后按下 Ctl + d。*Unix 中表示“没有更多输入/输入结尾”，处理文件时，是“文件结束”的含义。内核收到没有更多输入的指示，并转发到 Stdin，cat 识别到“文件结束”信号，认为到达当前读取文件的末尾。与所有 Unices 一样，对待，将一切当作普通文件，停止从内核读取。

　　实际上动态性质的终端 StdIO 文件并不是硬盘上的普通文件，而是由内核 API 管理的 Stdin 和 Stdout 链接。

如何在内核中实现 StdIO？

简短论述设计考虑（待续）

　　大多数早期开发者并没有考虑他们的内核需要为程序实现某种形式的标准输入输出。操作系统开发者最早开发的控制台驱动和键盘驱动应当成为标准输入输出的驱动程序的一部分。

　　Stdin 和 Stdout 不一定必须和键盘设备、控制台屏幕或者其它屏幕输出。一个程序可能打开一个文件句柄，将其作为标准输出流写入。

　　目前绝大部分内核包含作者的，在引导时实现任何形式的 Stdout 是没有意义的：除了内核没有任何程序可以使用。除此之外内核需要支持将 Stdout 绑定到多个流。

　　尽管屏幕不是唯一可以绑定 StdOut 的设备或资源，但必须注意的是，从所有迹象来看，所有的 OS 开发者都会编写一个在引导时直接引用 VGA 文本模式帧缓冲区的驱动程序。这不是错误或者有害的，但当内核能够运行程序时，必须存在一个资源支持将控制台屏幕作为标准输出资源。当然，由于缺乏适当的设计，在引导后内核图形部分必须起作用时，很多人仍然没有编写 Stdout 接口。

　　通常可以认为 Stdout 是程序可以访问的读写流。

　　让我们做一个简单的实验来了解 *Nix 中 StdIO 终端文件会发生什么：在 *Nix 中打开两个终端窗口。一个终端输入：cat /dev/pts/1（你实际的当前终端设备）并回车确认。会发现 Cat 开始从终端中读取。

　　在第二个终端输入 echo <输入随机单词>。注意当 shell 从键盘读取键盘输入时，允许通过转义来输入不可打印字符。
当输入：

　　echo hello <enter> Jane<enter> I'm glad to meet you

　　后入两张卡，划开外壳。

　　没有开出红色传说，依然是熟悉的白色降速盘。

　　完全拆出送入 NAS，希望它能和前辈一样勤恳工作。


　　熟悉的型号，熟悉的通电次数。

　　随便测个速。

　　索然无味的开箱，就这样了~~

安装 hexo-deployer-cos

　　在 package.json 下的 dependencies 中添加：

1

"hexo-deployer-cos": "^1.0.0"

配置 hexo-deployer-cos

　　在_config.yml 中填写配置信息。由于配置文件会上传到 github 中，为了安全文件不保存 SecretID 和 SecretKey。

1
2
3
4
5
6
7

deploy: 
  type: cos
  appId: 1234567890
  secretId: SecretId
  secretKey: SecretKey
  bucket: iloft-1234567890
  region: ap-shanghai

配置 Travis-CI

配置环境变量

　　与使用 Travis CI 一样，我们首先在 Repo/Setting/Secrets 里配置需要环境变量。

配置文件

　　创建并编辑 .github/workflows/deploy.yml ，与 Travis CI 格式大同小异，仍然需要使用 sed 命令替换隐私信息。由于Github Action支持私有仓库，如果是私有仓库可以直接在配置文件里填写敏感信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

name: Deploy

on:
  push:
    braches: 
      - master

jobs:
  build:
    runs-on: ubuntu-18.04

    steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-node@v1
      with:
        node-version: '10.x'

    - name: Setup Hexo & COS env
      env:
        SecretId: ${{ secrets.SecretId }}
        SecretKey: ${{ secrets.SecretKey }}

      run: |
        npm install hexo-cli -g
        npm install
        sed -i "s/SecretId/${SecretId}/" _config.yml
        sed -i "s/SecretKey/${SecretKey}/" _config.yml
    
    - name: Deploy to COS
      run: |
        hexo clean && hexo g && hexo d

    - name: Deploy to Github Pages
      env:
        GH_REF: github.com/myloft/blog
        CI_TOKEN: ${{ secrets.CI_TOKEN }}
        
      run: |
        git clone https://${GH_REF} .deploy_git
        cd .deploy_git
        git checkout master
        cd ../
        mv .deploy_git/.git/ ./public/
        cd ./public
        git init
        git config user.name "Yu"
        git config user.email "admin@iloft.xyz"
        git add .
        git commit -m ":memo:\ Update blog by Actions"
        git push --force --quiet "https://${CI_TOKEN}@${GH_REF}" master:gh-pages

Cookie & Session

　　由于 Http 具有无状态性，因此一般使用 Cookie & Session 保存用户的登录状态。

验证流程

1. 用户向服务器发送用户名和密码。
2. 服务器验证用户提交的用户名和密码，将当前用户的信息和状态保存到 Session 生成对应的 Session id，保存到浏览器 Cookie 中。
3. 用户此后的请求中携带着包含 Session id 的 Cookie。
4. 服务器根据 Session id 读取相应的 Session。

　　使用 Cookie & Session 虽然解决了用户状态问题但存在着一些弊端。

弊端

1. 需要在服务器端保存大量数据，不利于服务器的水平扩展。
2. 易遭受跨域攻击。

Token

　　由于 Session 的弊端，Token 将用户状态保存在客户端中，认证流程与使用 Cookie & Session 方式相似。

验证流程

1. 用户向服务器发送用户名和密码。
2. 服务器验证用户提交的用户名和密码，将用户信息加密生成 Token 返回给用户，用户将其存储 localstorage 等容器中。
3. 用户下次请求时将 Token 放入 Header、Body 、URL 中的一种。
4. 服务器将用户传来的 Token 解密，就可以确定用户的身份了。

优势

1. 可以用于 Restful API 中。
2. 以时间（Token 解密）换取空间（Session），解决了水平扩展的问题。
3. 可以抵御跨域攻击。

JWT(JSON Web Token)

　　JWT 是一种 Token 的实现标准（RFC 7519），JWT 由三部分组成。

Header（头部）

1
2

{"typ": "JWT",
 "alg": "HS256"}

1. typ:Token 的类型（type）。
2. alg: 签名算法（algorithm），默认使用 HMAC SHA256，缩写为 HS256。

Payload（负载）

1
2
3

{"iss":"joe",
 "exp":1300819380,
 "http://example.com/is_root":true}

　　RFC 7519 规定了七种保留字段以供选用，除此以外可以自行定义。

1. iss: 签发人（Issuer）。
2. sub: 主题（Subject）。
3. aud: 受众（Audience）。
4. exp: 过期时间（Expiration Time）。
5. nbf: 生效时间（Not Before）。
6. iat: 签发时间（Issued At）。
7. jti: 唯一编号（JWT ID）。

Signature（签名）

　　首先对 Header 和 Payload 进行 Base64Url 编码，指定一个密钥（secret），使用 Header 中的加密算法产生密钥。

1

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

　　算出 Signature 后以Header.Payload.Signature格式组成 JWT。

弊端

1. JWT 一旦泄露，所有人都能获取到其全部权限。
2. 服务端无法注销 Token，只能等待过期。

　　根据文档描述 SecureJSON 可以防止 json 劫持，如果给定的结构是数组值，则默认预置 "while(1);" 到响应体。

1
2
3
4
5
6
7
8

func securejson() {
r := gin.Default()
names := []string{"lena", "austin", "foo"}
r.GET("securejson", func(c *gin.Context) {
c.SecureJSON(http.StatusOK, names)
})
r.Run()
}

　　运行示例代码，响应体被插入了"while(1);"。

1
2

λ curl http://127.0.0.1:8080/securejson
while(1);["lena","austin","foo"]

　　根据文档的描述将 Array 修改成 Map。

1
2
3
4
5
6
7
8
9
10

func securejson() {
r := gin.Default()
r.GET("securejson1", func(c *gin.Context) {
c.SecureJSON(http.StatusOK, gin.H{
"names": "Yu",
})
})

r.Run()
}

　　此时响应体前并未添加"while(1);"。

1
2

λ curl http://127.0.0.1:8080/securejson1
{"names":"Yu"}

　　难道[]是造成的所谓 JSON 劫持的原因吗，JSON 劫持到底是什么，通过查阅资料找到了一段示例代码。
　　某银行可以通过某个 Get 方法的 API 获取已登录用户的账户余额。

1
2
3
4
5
6
7
8
9

GET https://mybank.com/users/balance
[
    {
        "userName": "jayden",
        "balance": 1200    },
    {         "userName": "oscar",
         "balance": 1200000        }
]
Cookie: XXXXXOOOXXXXX

　　正常情况下 Cookie 和同源策略可以阻止 JS 跨域获取数据，那攻击者该如何获取到数据呢。在浏览器控制台实验发现以[]开头的 Javascript 代码可以直接执行。

1
2

eval('[1,2,3]');
Array(3) [ 1, 2, 3 ]

　　也就是说如果将[]格式的数据放入<script>标签下可以直接被执行，即便如此又该如何获取到数据呢？这时候 Javascript 覆盖和重写特性就被利用了－如果有多个重名的函数与方法只有最后一个定义的有效。攻击者通过重写默认的Array()函数，并将返回[]格式的 API 放入<script>标签下，一旦运行到[就会调用覆写的Array()来窃取数据。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<script>function Array(){
    var that = this;
    var index = 0;
    var valueExtractor = function(value) {
      // Alert the value
      alert(value);
      // Set the next index to use this method as well
      that.__defineSetter__(index.toString(),valueExtractor );
      index++;
    };
    // Set the setter for item 0
    that.__defineSetter__(index.toString(),valueExtractor );
    index++;}

<script>
<script src="https://mybank.com/users/balance"></script>

　　主流浏览器通过删除__defineSetter__阻止覆写修复了该漏洞。但随着 ES6 Proxy 的发布，Array()又可以被覆写利用了。尽管浏览器很快修复了这些漏洞，Google、Facebook 等厂商通过在自己的 API 前添死循环阻止执行到[，也是为了避免今后出现其它利用方法。客户端则需要先将附加的安全头去除再进行处理。
　　这也是为什么 Gin 的 SecureJSON 不对{}格式的 JSON 进行处理，JS 会首先检查语法，导致{}格式的 API 无法被执行。

1
2

eval('{"key":"value"}');
SyntaxError: unexpected token: ':'

　　虽然只是一个小问题，但深入研究探究其中的缘由还是很有趣的。

　　首先通过观察服务器的响应头中的 X-Powered-By 字段可以发现服务端采用的是 ThinkPHP。随意构造一个链接发现未关闭 Debug 模式，使用的 ThinkPHP 版本为 3.2.2。

1
2
3
4
5
6
7
8
9
10
11
12
13

<?php
namespace Home\Controller;
use Think\Controller;
use Think\Verify;

class IndexController extends Controller
{
    public function index()
    {
        $verify = new Verify($config);
        $verify->entry();
    }
}

　　访问首页，成功显示验证码图像。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class IndexController extends Controller
{
    public function index()
    {
        $config = array(
            'useImgBg' => false,           // 使用背景图片
            'fontSize' => 16,              // 验证码字体大小(px)
            'useCurve' => true,            // 是否画混淆曲线
            'useNoise' => false,           // 是否添加杂点
            'imageH'   => 37,              // 验证码图片高度
            'imageW'   => 120,             // 验证码图片宽度
            'length'   => 4,               // 验证码位数
            'codeSet'  => '0123456789',    // 验证码字符集合
        );
        for($num = 0; $num < 10; $num++) {
            $verify = new Verify($config);
            $verify->entry();
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// 保存验证码
$key                   = $this->authcode($this->seKey);
$code                  = $this->authcode(strtoupper(implode('', $code)));
$secode                = array();
$secode['verify_code'] = $code; // 把校验码保存到session
$secode['verify_time'] = NOW_TIME; // 验证码创建时间
session($key . $id, $secode);

header('Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate');
header('Cache-Control: post-check=0, pre-check=0', false);
header('Pragma: no-cache');
header("content-type: image/png");

// 输出图像
imagepng($this->_image);
imagedestroy($this->_image);

　　阅读 PHP 文档了解 imagepng() 的使用方法，修改代码实现保存。

1
2
3

// 保存验证码
imagepng($this->_image, $code.'.png');
imagedestroy($this->_image);

　　访问网页根目录下出现了一张验证码图像。

1
2

imagepng($this->_image, $code[0].$code[1].$code[2].$code[3].'.png');
imagedestroy($this->_image);

　　访问网页，此时出现了一张正确命名的验证码图像。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public function index()
{
    $config = array(
        'useImgBg' => false,           // 使用背景图片
        'fontSize' => 16,              // 验证码字体大小(px)
        'useCurve' => true,            // 是否画混淆曲线
        'useNoise' => false,           // 是否添加杂点
        'imageH'   => 37,              // 验证码图片高度
        'imageW'   => 120,             // 验证码图片宽度
        'length'   => 4,               // 验证码位数
        'codeSet'  => '0123456789',    // 验证码字符集合
    );
    for($num = 0; $num < 10; $num++) {
        $verify = new Verify($config);
        $verify->entry();
    }
}

　　数字识别小组最终确认的项目是识别软微综合信息服务平台的验证码。由于之前本科毕设做的是车牌识别，接触过一些验证码识别项目。识别验证码其实已经有很多人在做，也有很多种方法。单从字符算法上来看就可以分为 SVM、随机森林等传统的机器学习算法以及最近几年非常火热的深度学习算法两种。目前主流实现思路依然是先采用一些图像学算法对验证码图像进行预处理，将其中的干扰点和干扰线进行清除后分割字符对每个字符进行识别。

　　以一张验证码为例，首先对其灰度化，通过调整阈值将大部分噪点清除。

　　这种方法看起来还是很简单的，但是毕设做车牌识别时的字符分割就没有那么简单了，首先车牌图像相对于图像的比例非常小且图像的质量受设备和天气的影响很大，一旦字符出现粘连，很大概率无法对车牌的字符进行分割。

　　除此以外，在图像尺寸较大时，ANN 深度无法过深，否则根本无法训练。因此，训练神经网络必须对图片进行切割，但是 CNN 的出现让我们可以考虑实现不分割字符一次性识别验证码或者车牌。

　　针对这种顺序书写的字符比如车牌以及验证码，使用RNN以及CTC可以在只知道序列顺序而不知道每个字符具体位置时让模型收敛。该模型最早由华中科技大学的白翔教授提出。这种模型不仅可以应用在图像中的文字识中，也可以实现对不定长的语音的识别。

　　除此以外按照新生入学小助手组的工作安排，周日抽出了点时间完成了一个 Restful 风格的 Python demo，无需赘述。

参考链接

• python 基于机器学习识别验证码
• 使用 Keras 来破解 captcha 验证码
• An End-to-End Trainable Neural Network for Image-based SequenceRecognition and Its Application to Scene Text Recognition

　　反复横跳…

笔试

　　我是计算机科班的，报的大数据转录，没有达到要求，参加了笔试。面试前一天参加笔试。笔试分为英语和逻辑两部分，一份试卷 A4 纸单面打印，答题时间三个小时。

笔试英语

　　英语题型有点类似江苏高考，选择 + 完形填空 + 阅读理解 + 作文。选择题分两部分考察，一部分考察语法如时态、虚拟语气等，应该是第一年出现这种题型，所以全靠语感来蒙；另一部分考察词汇也就是词汇辨析，认识自然就能得分了。完形填空和阅读理解比较简单，肯定是没有英语二难的，有没有四级难度都难说。作文一篇，题目大概是设想手机消失会发生什么，写的时候考研政治上头，经济、政治、文化、社会、生态一顿瞎写。

笔试逻辑

　　逻辑题型参见 MBA 与 GCT 逻辑。一个题干可以有多个问题，四选一。考前做了几套卷子了解了一下题型，了解了常见的错误，除了上面所说的逻辑题还有一些小学数学题，比如「粗细蜡烛」、「圆形花圃间隔栽花」。

笔试总结

　　总体来说笔试不难，英语和逻辑都有拿到 90 分以上的大佬，如果转录分数不高比如 25 分以下建议参加笔试。

面试

　　面试前一天准备了一晚上英语自我介绍，最终没有派上用场。到了面试地点，点完名要求现场做张卷子再面试，三选二。分别是「内切圆半径的简单计算」、「矩阵的简单计算」、「抽次品（条件概率）」。时间非常充沛，题目非常简单，然而考完研的我就把这些东西都忘了，最终只做出了一道半。

英语面试

　　做完之后就是排队等待面试。面试全程录像，进去之后将手上的准考证递给我右前方的老师，中间的老师和左边的老师先扫了眼个人材料，发现我是科班的，三个老师互相交流评价了一下「学校还不错嘛」，然后问了一下「你们的校长还是 XX 吗？」，由于没有印象被调侃「上了四年学连校长是谁都不知道？」、「你这个题目怎么就写对了一道。」随后开始面试，先由中间的郁莲教授面试英语，由于她的研究方向是软件理论，我本科学过《软件工程》。所以先提问「软件工程的英文怎么说？」答完这个问题之后噩梦开始，开始纯英文问答，由于我大四的《专业英语》被砍加上《软件工程》这门课已经遗忘干净，之后的提问如「Software engineering workflow」，只能非常尴尬的中英混答，表示我知道是什么然而用英语答不上来。

技术面试

　　熬完英语问答之后，左前方的老师瞄了一眼郁莲教授手中的成绩单，说「你数据结构学得不错，Prim 算法是贪心算法吗？」，我有些迟疑「应该是贪心算法吧。」然后让我分别解释了「Prim 算法」和「贪心算法」的概念，我用自己的话解释了一遍，其间老师一直在边听记录，还不忘安慰我「别紧张，能听出来你都懂。」

　　由于我在解释的时候类比了梯度下降。于是老师提问「局部最优点和全局最优点是什么关系？」「梯度下降可能存在一个点既是最高点又是最低点吗？」「鞍点是什么点？」由于紧张这几个问题我都答得不好，甚至答错了，回头查资料的时候发现老师在我答错的时候一直在引导我。问完了技术问题，老师边低头记录边问「有没有做过大数据分析的相关的项目」，我就坦白的回答「之前在学校里学过 Hadoop，做过 WordCount 实验，毕设的时候同组同学做了抗药性预测和推荐系统，答辩的时候我去听了。」「可以了，差不多了」拿着我的准考证的老师递过准考证和名单并让我签字，示意我可以离开了。离开时听到技术面的老师和其他老师交流「基础还不错。」

　　由于当时比较紧张，提前准备的关于深度学习的毕设的介绍也没能提起，实际上老师最后问有没有相关项目时可以提一下。不过最终还是被录取了，也就没有留下遗憾了。

　　主路由器为K3，从路由器为K2P同配置的友华1200js。家里的网段为172.16.0.0/16，主路由器网关为172.16.0.1。尝试了两种方法来实现两路由器下设备在同一网段。

优雅的方法（LAN Bridge）

　　比较优雅的方法是将从路由设置的IP设置在同一网段，如172.16.0.2，并关闭DHCP。按正常方式扫描WIFI并加入网络，再将接口从WWAN修改为LAN，最后删除自动创建的WWAN接口即可完成配置。

　　这种直接桥接的方式最为优雅，主路由器、从路由器、各路由器下的设备都在同一网段，无需路由器转发通讯。然而实际配置时出现了无线无法启动的问题。

　　经过搜索发现MT7615的驱动并不支持Wireless与Lan桥接模式。但在另一台路由器EA6350上成功实现。

通用方法（Relay）

　　通用的方法是对LAN与WWAN进行转发，效率没有直接桥接高。

加入网络

　　这种方式从路由器与主路由器不在同一网段，如192.168.1.1，关闭DHCP。按正常方式扫描WIFI并加入网络。此时可以通过设置PC的网关为192.168.1.1正常上网。

安装软件包

　　为了实现转发，需要安装relayd和luci-proto-relay两个包，如果是一些定制固件可能已经包含了。

1
2

opkg update
opkg install luci-proto-relay

创建转发

　　在网络接口点击创建新的网络接口，如命名为RELAY，选择接口类型为Relay bridge。

　　配置上一步创建的RELAY接口，将lan和wwan加入转发。

配置防火墙

　　完成转发配置之后需要配置防火墙，将Forward修改为为accept。

测试网络

　　此时从路由器下的设备就可以通过DHCP获得正确的IP地址和网关了，可以正常联网并与局域网内的设备进行通信了。由于采用了Relay方式，路由追踪略微有些美中不足。

安装hexo-deployer-cos

　　在package.json下的dependencies中添加：

1

"hexo-deployer-cos": "^1.0.0"

配置hexo-deployer-cos

　　在_config.yml中填写配置信息。由于配置文件会上传到github中，为了安全文件不保存SecretID和SecretKey。

1 2 3 4 5 6 7

deploy: type: cos appId: 1234567890 secretId: SecretId secretKey: SecretKey bucket: iloft-1234567890 region: ap-shanghai

配置Travis-CI

　　在Travis-CI项目设置界面中配置环境变量。

　　修改.travis.yml，与只部署到Github Pages相比，增加了将SecretId与SecretKey替换成为预设的环境变量的sed命令和hexo d命令。完整的部署到COS和Github Pages配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

language: node_js
node_js: stable
cache:
  directories:
    - node_modules

# S: Build Lifecycle
install:
  - npm install


#before_script:
 # - npm install -g gulp

script:
  - sed -i "s/SecretId/${SecretId}/" _config.yml
  - sed -i "s/SecretKey/${SecretKey}/" _config.yml
  - hexo clean && hexo g && hexo d

after_script:
  - git clone https://${GH_REF} .deploy_git
  - cd .deploy_git
  - git checkout master
  - cd ../
  - mv .deploy_git/.git/ ./public/
  - cd ./public
  - git init
  - git config user.name "Yu"
  - git config user.email "admin@iloft.xyz"
  - git add .
  - git commit -m ":memo:\ Update blog by CI"
  - git push --force --quiet "https://${CI_TOKEN}@${GH_REF}" master:gh-pages
# E: Build LifeCycle

branches:
  only:
    - master
env:
 global:
   - GH_REF: github.com/myloft/blog