LLM on niuzj

给 AI Agent 加状态机，踩了个 instruction 注入的坑

Fri, 10 Apr 2026 00:00:00 +0000

做 Agent 做到一定复杂度，一定会遇到这个问题：多步骤流程怎么编排。

我们的场景是 UGC 视频制作——用户说"帮我做一条唇釉的带货视频"，Agent 需要走完意图分析、搜索对标、制定策略、仿写脚本、达人选角、生成素材这一整套流程。每一步都有不同的指令，需要调不同的工具，用户还可能在任何一步说"不满意，重来"。

靠 system prompt 里写一大段流程说明让 LLM 自己记住做到哪了？试过，对话一长就乱。跳步、重复、忘记之前收集的信息，各种问题。

所以我们给 Agent 装了一个状态机。

为什么是状态机

状态机的核心价值是把"Agent 应该做什么"从 LLM 的记忆里抽出来，变成一个确定性的外部数据结构。

不用状态机的时候，Agent 的行为完全依赖 LLM 对上下文的理解。LLM 需要从几十轮对话历史里推断出"我现在在第几步、下一步该做什么、之前收集了哪些信息"。这在 3-5 轮对话里还行，到了 10+ 轮就不可靠了。

用了状态机之后，每一轮对话开始时，系统从外部状态里读出"当前在哪一步"，把这一步的 instruction 注入到 LLM 的上下文里。LLM 不需要记忆，它只需要执行当前步骤的指令。

这个思路不是我们发明的。研究了 30 多个开源 Agent 框架后发现，所有做多步骤编排的框架本质上都是这个模式：

                    ┌─────────────────────┐
                    │    状态机 / 工作流    │
                    │  （确定性，外部维护）  │
                    │                     │
                    │  当前步骤 → instruction
                    │  转移条件 → 下一步    │
                    │  共享数据 → state.data │
                    └──────────┬──────────┘
                               │ 注入 instruction
                               ▼
                    ┌─────────────────────┐
                    │     LLM Agent       │
                    │  （概率性，执行层）   │
                    │                     │
                    │  看到 instruction    │
                    │  → 调用工具          │
                    │  → 回复用户          │
                    │  → 推进状态机        │
                    └─────────────────────┘

确定性的编排层告诉 Agent “该做什么”，概率性的 Agent 层决定"怎么做"。两层各管各的。

让 LLM 同时返回文字和结构化数据：用假 Tool Call 做 Side Channel

Wed, 08 Apr 2026 00:00:00 +0000

最近在做 AI Agent 的时候碰到一个很实际的问题：LLM 回复用户的时候，除了正常的文字，还需要同时返回一份结构化的 JSON 给前端渲染 UI 组件。

比如用户问"帮我分析一下这几个模板，推荐最适合的"，Agent 需要：

用文字解释推荐理由（给用户看）
同时返回一个结构化的推荐列表（给前端渲染可点选的卡片）

这两个东西必须在同一轮对话里出来。

直觉方案：让 LLM 在文本里嵌 JSON

最容易想到的办法是在 system prompt 里约束 LLM，让它在回复末尾加一段 JSON：

你的回复格式：
先用自然语言回答用户，然后在末尾用 ```json 代码块输出推荐数据...

这个方案能跑，但很脆弱：

你得写正则或者找分隔符从文本里提取 JSON
LLM 有时候会把 JSON 格式搞乱，多个反引号、漏个逗号
流式输出的时候更麻烦，你不知道 JSON 什么时候开始什么时候结束
prompt 越复杂，LLM 越容易忘记遵守格式

正经方案：三家 API 的 Structured Output

先看看三大 LLM 厂商怎么解决"让模型输出结构化数据"这个问题。

OpenAI 有原生的 response_format：

curl https://api.openai.com/v1/chat/completions \
  -d '{
    "model": "gpt-4o",
    "response_format": {
      "type": "json_schema",
      "json_schema": {
        "name": "recommendations",
        "strict": true,
        "schema": {
          "type": "object",
          "properties": {
            "items": {
              "type": "array",
              "items": {
                "type": "object",
                "properties": {
                  "title": {"type": "string"},
                  "reason": {"type": "string"}
                },
                "required": ["title", "reason"]
              }
            }
          },
          "required": ["items"]
        }
      }
    },
    "messages": [{"role": "user", "content": "推荐3个适合电商的工作流模板"}]
  }'

strict: true 保证输出 100% 符合 schema。

用 PostHog 监控你的 AI Agent：从调用追踪到成本核算

Mon, 20 Oct 2025 00:00:00 +0000

最近在公司做一个 Agent 项目，跑通了基本流程之后，遇到一个很现实的问题：线上用户反馈"回答不对"或者"响应太慢"，我根本没法排查。日志里只有零散的 print，完全看不出一次对话里到底调了几次模型、每次花了多久、tool call 有没有报错。

我需要一个能看清 Agent 每一步在干什么的监控工具。

PostHog 的 LLM Analytics

偶然看到 PostHog 出了 LLM observability 的功能，抱着试试的心态接了一下，发现这东西是真的好用。

PostHog 把 AI Agent 的监控拆成了三层：

Trace — 一次完整的用户对话
Generation — 每一次 LLM API 调用
Span — 每一次 tool 执行

这个层级结构跟 Agent 的实际运行方式完全对应。一个用户提问进来，Agent 可能调 3 次模型、执行 5 个 tool，这些全部串在一个 trace 下面，一目了然。

接入过程

接入非常简单，核心就是在几个关键节点上报事件。

初始化一个 client：

from posthog import Posthog

client = Posthog(
    api_key="phc_xxx",
    host="https://us.i.posthog.com"
)

每次 LLM 调用完成后，上报一个 $ai_generation 事件：

client.capture(
    distinct_id=user_id,
    event="$ai_generation",
    properties={
        "$ai_model": "gpt-4o",
        "$ai_provider": "openai",
        "$ai_input": messages,
        "$ai_output_choices": response.choices,
        "$ai_input_tokens": usage.prompt_tokens,
        "$ai_output_tokens": usage.completion_tokens,
        "$ai_cache_read_input_tokens": cached_tokens,  # 别漏了这个，后面会讲
        "$ai_latency": 1.23,
        "$ai_trace_id": trace_id,
        "$ai_tools": tools,
    }
)

tool 执行完上报一个 $ai_span：