1
import os
2
from dotenv import load_dotenv
3
from openai import OpenAI
4

5
load_dotenv()
6

7
_PROVIDERS = {
8
    # provider -> (base_url, api_key 环境变量名)
9
    "glm": ("https://open.bigmodel.cn/api/paas/v4", "GLM_API_KEY"),
10
    "deepseek": ("https://api.deepseek.com/v1", "DEEPSEEK_API_KEY"),
11
}
12

13
def get_client() -> tuple[OpenAI, str]:
14
    """返回 (OpenAI 兼容客户端, 模型名)。"""
15
    provider = os.getenv("LLM_PROVIDER", "glm").strip().lower()
16
    model = os.getenv("LLM_MODEL", "").strip()
17
    if not model:
18
        raise RuntimeError(".env 中未设置 LLM_MODEL")
19

20
    if provider == "openai":
21
        base, key = os.getenv("OPENAI_API_BASE"), os.getenv("OPENAI_API_KEY")
22
    elif provider in _PROVIDERS:
23
        base, key_env = _PROVIDERS[provider]
24
        base = os.getenv(f"{provider.upper()}_BASE_URL") or base
25
        key = os.getenv(key_env)
26
    else:
27
        raise RuntimeError(f"未知 provider: {provider}")
28

29
    if not base or not key:
30
        raise RuntimeError(f"provider={provider} 缺少 base_url 或 api_key")
31

32
    return OpenAI(base_url=base, api_key=key), model

1
POLICY = """【退货政策】
2
1. 签收后 7 天内可无理由退货
3
2. 食品/贴身衣物类目不支持无理由退货
4
3. 商品已拆封且影响二次销售的，仅支持换货不支持退款
5
4. 因质量问题退货，运费由平台承担；非质量问题，运费买家自理
6
5. 订单金额超过 5000 元需人工复核"""
7

8
WORK_ORDER = """【退货工单】
9
- 商品：某品牌蓝牙耳机
10
- 订单金额：329 元
11
- 类目：数码配件
12
- 签收时间：5 天前
13
- 退货原因：买家称「音质与描述不符」
14
- 商品状态：已拆封，包装完整，配件齐全
15
- 买家要求：全额退款"""
16

17
SYSTEM_PROMPT = (
18
    "你是某电商平台的售后审核 AI，负责根据退货政策对退货工单做合规判定。\n"
19
    "你必须用「Step 1 → Step 2 → ... → 最终结论」的格式，逐条对照政策逐步推理，"
20
    "推理过程要完整写在正文里，不要省略中间步骤。最后给出："
21
    "①判定结果（退 / 换 / 驳回）；②给买家的一句话话术。"
22
)
23

24
def main():
25
    _, model = get_client()
26
    print("推理输出（Step 1 → Step 2 → ... → 最终结论）：\n")
27

28
    msg = chat([
29
        {"role": "system", "content": SYSTEM_PROMPT},
30
        {"role": "user", "content": f"{POLICY}\n\n{WORK_ORDER}\n\n请开始逐步推理。"},
31
    ])
32
    print(msg.content)

1
Step 1：判断时效。工单显示签收于 5 天前，在 7 天无理由退货期内 → 时效满足。
2

3
Step 2：判断类目。商品是蓝牙耳机，属于数码配件，不属于食品/贴身衣物 → 类目限制不适用。
4

5
Step 3：判断拆封情况。商品已拆封，但"包装完整，配件齐全"，是否影响二次销售需酌情判断；
6
        音质与描述不符属于体验类问题，拆封是验机的必然结果 → 可支持退货。
7

8
Step 4：判断运费承担。退货原因是"音质与描述不符"，属于商品与描述不符的质量/描述问题，
9
        非买家无理由退货 → 运费应由平台承担。
10

11
Step 5：判断是否人工复核。订单金额 329 元 < 5000 元 → 无需人工复核。
12

13
最终结论：
14
①判定结果：支持全额退款，退货运费由平台承担。
15
②话术：您好，您的退货申请已审核通过，本单支持全额退款且运费由平台承担，请按指引寄回商品即可。

1
def query_metrics(service: str, metric: str = "", minutes: int = 30) -> dict:
2
    """查监控指标：CPU / 内存 / DB 连接池 等。"""
3
    key = (metric or "").lower()
4
    if any(w in key for w in ("db", "connection", "conn", "pool", "连接", "连接池")):
5
        return {
6
            "db_connection_pool": "已打满 10/10",
7
            "max_pool_size": 10,
8
            "active_connections": 10,
9
            "note": "数据库连接池耗尽，新请求拿不到连接",
10
        }
11
    if any(w in key for w in ("cpu", "memory", "mem", "资源")):
12
        return {
13
            "cpu_usage": "85%",
14
            "memory_usage": "60%（正常）",
15
            "note": "CPU 偏高但未打满，内存无压力",
16
        }
17
    return {
18
        "cpu_usage": "85%",
19
        "memory_usage": "60%（正常）",
20
        "db_connection_pool": "已打满 10/10",
21
        "note": "综合指标：CPU 偏高，连接池打满是最明显异常点",
22
    }
23

24

25
def query_logs(service: str, keyword: str = "ERROR", minutes: int = 30) -> dict:
26
    """按关键字查询服务日志。"""
27
    kw = (keyword or "").lower()
28
    error_like = any(w in kw for w in ("error", "exception", "conn", "pool", "连接", "报错"))
29
    if not error_like and kw not in ("", "log"):
30
        return {"count": 0, "note": f"关键字「{keyword}」无匹配日志"}
31
    return {
32
        "level": "ERROR",
33
        "count": 382,
34
        "samples": [
35
            "com.zaxxer.hikari.pool.HikariPool: HikariPool-1 - Connection pool exhausted",
36
            "java.sql.SQLTransientConnectionException: Connection is not available, "
37
            "request timed out after 30000ms",
38
            "org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection",
39
        ],
40
        "note": "大量『连接池耗尽』类报错",
41
    }
42

43

44
def query_deploy_history(service: str) -> dict:
45
    """查询服务最近 24 小时的发布记录。"""
46
    return {
47
        "deploys": [{
48
            "time": "2 小时前",
49
            "version": "v2.4.1",
50
            "operator": "ci-bot",
51
            "changes": [
52
                "DB 连接池配置 max_pool_size: 50 → 10",
53
                "日志级别由 INFO 调整为 WARN",
54
            ],
55
        }],
56
        "note": "最近 24 小时仅此一次发布",
57
    }
58

59

60
def query_upstream(service: str) -> dict:
61
    """查询上下游依赖（MySQL / Redis 等）状态。"""
62
    return {
63
        "mysql_primary": "正常（连接数 30/500）",
64
        "redis": "正常（内存 40%，无慢查询）",
65
        "note": "上游依赖均正常，可排除外部原因",
66
    }

1
TOOLS = [
2
    {
3
        "type": "function",
4
        "function": {
5
            "name": "query_metrics",
6
            "description": "查询监控指标（CPU、内存、DB 连接池等）",
7
            "parameters": {
8
                "type": "object",
9
                "properties": {
10
                    "service": {"type": "string", "description": "服务名"},
11
                    "metric": {"type": "string", "description": "指标名，可留空"},
12
                    "minutes": {"type": "integer", "description": "回溯最近多少分钟"},
13
                },
14
                "required": ["service"],
15
            },
16
        },
17
    },
18
    # ... 其余 3 个工具定义结构相同
19
]

1
SYSTEM_PROMPT = """你是一名资深 SRE 值班工程师，正在排查线上告警。你有以下 4 个工具可用：
2
- query_metrics(service, metric, minutes)：查监控指标（CPU/内存/DB连接池等）
3
- query_logs(service, keyword, minutes)：按关键字查服务日志
4
- query_deploy_history(service)：查最近 24 小时发布记录
5
- query_upstream(service)：查上下游依赖（MySQL/Redis 等）状态
6

7
排查要求：
8
1. 采用「想一步、查一步、看一步」的节奏：每次调用工具前，先输出一行「Thought:」说明你的分析和下一步要查什么。
9
2. 每次只调用一个工具，根据返回的 Observation 结果再决定下一步，不要一次把所有工具都查了。
10
3. 逐步缩小范围直到找到根因；找到根因后停止调用工具，输出「Final Answer:」给出根因、依据和处置建议。"""
11

12
USER_PROMPT = """【告警信息】
13
- 服务：order-service
14
- 接口：/api/order/create
15
- P99 延迟：200ms → 3.2s（飙升 16 倍）
16
- 错误率：0.1% → 12%
17

18
现在是凌晨 3 点，请开始排查，找出根因。"""

1
MAX_STEPS = 8   # 防止无限循环的保险丝
2

3
def main():
4
    _, model = get_client()
5
    print("排查过程（Thought → Action → Observation 循环）：\n")
6

7
    messages = [
8
        {"role": "system", "content": SYSTEM_PROMPT},
9
        {"role": "user", "content": USER_PROMPT},
10
    ]
11

12
    step = 0
13
    while step < MAX_STEPS:
14
        msg = chat(messages, tools=TOOLS)
15

16
        # 模型不再调用工具 → 输出 Final Answer，循环结束
17
        if not msg.tool_calls:
18
            print(f"\n[Final Answer]\n{msg.content}")
19
            break
20

21
        step += 1
22
        thought = re.sub(r"^Thought\s*[:：]\s*", "", (msg.content or "").strip(), flags=re.I)
23
        print(f"[Thought {step}] {thought or '（模型未输出思考文本）'}")
24
        messages.append(msg)
25

26
        for i, tc in enumerate(msg.tool_calls, start=1):
27
            label = f"[Action {step}]" if len(msg.tool_calls) == 1 else f"[Action {step}-{i}]"
28
            print(f"{label} {tc.function.name}({tc.function.arguments})")
29
            observation = run_tool(tc.function.name, tc.function.arguments)
30
            print(f"[Observation {step}] {observation}\n")
31
            messages.append({
32
                "role": "tool",
33
                "tool_call_id": tc.id,
34
                "content": observation,
35
            })
36
    else:
37
        print(f"\n[警告] 达到最大步数 {MAX_STEPS} 仍未给出 Final Answer，已终止。")

1
[Thought 1] 延迟飙升且错误率上升，先看是不是资源瓶颈，查 CPU 和内存。
2
[Action 1] query_metrics({"service": "order-service", "metric": "cpu_memory", "minutes": 30})
3
[Observation 1] { "cpu_usage": "85%", "memory_usage": "60%（正常）", ... }
4

5
[Thought 2] CPU 偏高但不离谱，内存正常。错误率 12% 说明有具体报错，去翻日志。
6
[Action 2] query_logs({"service": "order-service", "keyword": "ERROR", "minutes": 30})
7
[Observation 2] { "count": 382, "samples": ["HikariPool-1 - Connection pool exhausted", ...] }
8

9
[Thought 3] 数据库连接池打满了。是资源泄漏还是配置问题？查一下最近有没有发布。
10
[Action 3] query_deploy_history({"service": "order-service"})
11
[Observation 3] { "deploys": [{ "version": "v2.4.1", "changes": ["DB 连接池配置 max_pool_size: 50 → 10"] }] }
12

13
[Thought 4] 破案了。连接池从 50 改成 10，扛不住流量。再确认不是上游数据库的问题。
14
[Action 4] query_upstream({"service": "order-service"})
15
[Observation 4] { "mysql_primary": "正常", "redis": "正常" }
16

17
[Final Answer]
18
根因：2 小时前的发布 v2.4.1 将 DB 连接池 max_pool_size 由 50 误改为 10，导致连接池打满。
19
依据：日志中大量 Connection pool exhausted；发布记录显示该配置变更；上游 MySQL/Redis 正常。
20
建议：立即回滚 v2.4.1 或热改连接池配置恢复到 50。