我用 TraeCode 把高风险文件清理设想做成了可运行的 Agent 后端
话题：TraeCode的100种用法
一、我是谁，以及我遇到了什么问题
我是一名软件工程专业的学生，正在学习 LLM Agent 应用开发。为了把 LangGraph、结构化输出和人工审批这些概念真正串起来，我设计了一个叫 SpaceDeletor 的项目：让 Agent 分析待清理文件的语义和删除风险，辅助用户判断哪些文件可以处理。
这个项目最棘手的地方并不是“让模型给出删除建议”，而是删除操作本身具有不可逆风险。如果只让大模型自由判断，很容易出现状态混乱、结论不可解释，甚至误删重要文件。因此我给项目设定了几项约束：
- 文件必须经过明确的处理流程，不能由模型直接删除；
- 用规则过滤明显危险的系统目录和文件；
- 将“提出处理建议”和“审查风险”拆成 Planner 与 Critic 两个节点；
- 所有节点通过结构化状态传递结果，并为最终操作保留人工审批环节。
刚开始时，这些设计散落在笔记和脑图里。真正落到 Python 代码时，我需要同时处理 LangGraph 的状态流转、Pydantic 数据约束、批量文件队列、节点返回值和结束条件。只要一个字段或分支没有对齐，流程就可能无法运行。我希望借助 TraeCode，把这套架构逐步变成能够实际执行的后端。
二、我是怎么用 TraeCode 解决这件事的
我主要使用的是 SOLO 模式。它对这个项目最大的帮助，不只是生成某一段代码，而是能够持续读取项目上下文，围绕同一个目标规划、修改并验证多个文件。
第一步：先把安全约束转成可执行的工作流
我先向 TraeCode 说明项目目标和边界。核心要求大意是：
这是一个 Agentic 文件清理系统。请先设计 Python 后端的最小可运行流程，用 LangGraph 管理状态。模型只能分析和给出建议，不能直接执行删除；需要拆分 Planner、Critic，并为规则校验和人工审批保留接口。
TraeCode 帮我把抽象需求拆成了更具体的组成部分：统一的 AgentState、负责生成建议的 Planner、负责风险复核的 Critic、控制节点流向的条件边，以及表示处理结果的状态枚举。
这一步让我意识到，复杂 Agent 项目不能只盯着提示词。真正决定系统能否稳定运行的，是每个节点“接收什么、返回什么”，以及状态如何在图中流动。
第二步：整理 AgentState，避免节点之间各说各话
接下来，我让 TraeCode 根据工作流统一状态字段，逐步梳理了文件队列、当前处理位置、批量处理结果和最终状态等数据，例如：
file_queue：等待处理的文件；current_index：当前处理到哪一个文件；batch_results：保存已经完成的分析结果；final_status：表示流程是继续、批次完成，还是等待后续确认。
我没有让模型一次性写完整项目，而是先要求它生成最小结构，再逐步增加字段和校验。每增加一个状态，我都会让 TraeCode 检查 Planner、Critic 和条件边是否仍然使用同一套定义。
第三步：拆开 Planner 和 Critic，形成可检查的决策链
早期版本里，分析文件和给出最终结论很容易混在同一个节点中。后来我借助 TraeCode 将职责拆开：
- Planner 根据文件信息生成候选处理建议；
- Critic 检查建议是否存在高风险、依据是否充分；
- 程序根据结构化结果决定继续处理、记录结果或进入人工确认。
我还让 TraeCode 对比两个节点的输入输出，检查是否有字段缺失或语义重复。这样做以后，即使模型给出的结论不合适，也能看出问题发生在建议阶段还是审查阶段，而不是只得到一个无法追溯的最终答案。
第四步：边运行边修正，让最小后端真正跑起来
完成基本节点后，我让 TraeCode 配合终端运行 Python 后端，并根据实际报错继续修改。调试重点包括：
- StateGraph 的节点注册和连接是否正确；
- 节点返回的数据能否写回统一状态；
current_index是否能够正常推进；- 批量处理完成后，流程能否进入预期的
final_status； - 枚举值和条件分支是否一一对应。
相比单独把报错复制到聊天工具里，SOLO 模式能够结合当前项目文件继续定位问题，修改之后再运行验证，减少了在编辑器、文档和聊天窗口之间反复切换。
三、成果展示
目前 SpaceDeletor 已经实现并跑通了 Python 后端功能。现阶段成果包括：
- 建立了基于 LangGraph 的状态工作流；
- 完成了统一的 AgentState 和关键状态枚举；
- 将 Planner 与 Critic 分成独立节点；
- 能够按队列处理任务、累计批量结果并返回最终状态；
- 为规则校验、模型分类和人工审批等后续安全层预留了清晰位置。
当前版本仍是后端阶段，我没有把尚未完成的前端联动或完整产品包装成已经交付的功能。但它已经从一套停留在笔记里的架构，变成可以运行、调试和继续扩展的程序骨架。后续可以在此基础上接入 Tauri 前端、WebSocket 通信，以及本地模型或云端模型切换。
四、效率对比
以前做这类学习项目时，我经常一边翻 LangGraph 文档，一边修改多个 Python 文件，再单独检查 Pydantic 模型和分支条件。项目稍微复杂后，很容易忘记某个字段在哪些节点被使用，时间大量消耗在重复查找和修补上下文上。
使用 TraeCode SOLO 模式后，我可以把目标、限制和当前进度持续放在同一个项目上下文中，让它协助完成“分析结构—修改代码—运行验证—根据报错修正”的闭环。我仍然需要决定架构和检查安全边界，但重复的文件定位、接口对齐和样板代码工作明显减少，也更容易把每次开发控制成一个可以验证的小任务。
对我来说，最大的效率提升不是简单的“代码生成得更快”，而是复杂想法能够更快进入可运行、可验证的状态。
五、经验和技巧总结
- 先告诉 Agent 不能做什么。 对文件删除、数据库修改等高风险任务，先明确禁止直接执行，再讨论功能实现。
- 先跑最小闭环，再逐步加功能。 一次生成完整系统很难判断错误来源；先让 StateGraph 跑通，再增加节点和字段更稳定。
- 把节点输入输出写清楚。 Planner、Critic 名字听起来很直观，但如果没有结构化字段约束，实际运行时仍然容易互相覆盖或遗漏信息。
- 不要把 AI 生成等同于完成。 TraeCode 可以规划、改代码和辅助调试，但状态流转、安全规则和最终操作仍然需要开发者检查。
这次实践让我真正理解了 Agent 工程和普通聊天应用的区别：模型只是系统中的一个决策组件，可靠性来自工作流、状态约束、验证机制与人工控制共同配合。
TraeCode的100种用法