把工单系统变成 agent 开发实验场：一次真实的工程实验
AI 编码 agent 要在真实软件项目里有用，需要什么？不是玩具仓库，不是单条快乐路径的绿地演示，而是有历史、有约定、有旧决策、有安全边界、有测试、有发布流程、有永远不够完整的需求的项目。这篇 dev.to 文章记录了一个叫 Lutions 的自托管工单系统如何从工具长成 agent 开发实验场——以及它揭示的工程问题。
起点：为什么是工单系统
起因是授权费上涨、被推向云专属工具的压力，以及作者对"数字主权"的不适。与其抱怨，不如试试自己建一个现代工单系统要花多大力气。工单系统是合适尺寸的起点：复杂到能暴露技术和组织问题，又有界到可以从定义明确的 MVP 起步、逐步成长。
随着时间推移，重心转移。Lutions 现在是一个项目与工单流程 Web 应用：权限、UI 约定、API 集成、发布流程、审计、不断增长的文档。这些听起来像普通管理软件——对这场实验来说，这种普通恰恰是重点。它把本地优先开发与生产级 QA、通向正式生产系统的刻意发布路径结合起来。
为什么普通应用是有用的测试台
在成熟代码库里工作的 agent 不能只是成功改一个文件。它需要理解某个模式为什么存在、哪些规则适用、期望什么证据、一个看似微小的改动可能在哪里产生后果。这接近 SWE-bench 描述的挑战：许多任务需要跨多个文件和函数的改动，而非孤立代码生成。SWE-agent 也指出：agent 可用的接口和反馈循环，决定它能否有效导航仓库、编辑代码、跑测试。
Lutions 不是基准，不是科学研究，是个人开发实验室。但它提出同一个实际问题：agent 在一个有约定、历史、风险、测试数据和社会协作的系统里工作时会发生什么。答案不是"更好的 prompt"——有用的 agent 需要一个让相关上下文和约束可及的环境。
应用变成了开发流程的一部分
有趣的变化是渐进的：偶发编码协助变成了一个问题——当一个 AI agent 定期为既有系统做贡献时，开发流程必须怎么运作？三个关注点浮上台面：
- 需求：如何把期望陈述到足够精确，让 agent 解决实际问题而不是产出看似合理的代码？
- 知识：如何让架构知识、安全约定和产品边界不消失在聊天历史里？
- 治理与评审：人工评审在哪里补充必要判断？哪些专用 agent 角色有帮助？什么仍必须独立测试？
在 Lutions 里，这些问题有实际的家：需求捕获为工单，工作步骤和决策可以文档化，评审、测试证据和流程变更可追溯。agent 因此不只"在 Lutions 上"工作，还"与 Lutions 一起、在 Lutions 里"工作。这个区别很重要：一个收到任务却拿不到项目上下文的 agent 往往为局部可见的结果优化；一个在流程内部工作的 agent 可以被要求检查相关源码、记录假设、运行成比例的检查、留下别人以后能评估的证据。
实际中，一个很小的改动就能让差异可见：给工单页加一个操作不只是 UI 任务——agent 可能需要检查相关权限、遵循既有交互模式、运行让改动可安全评审的检查。代码改动只是工作的一部分。这不是为流程而流程，是让快节奏工作流可检查到足以被信任。
上下文才是真正的工程问题
关于 agentic AI 的公开讨论常聚焦自主性、工具使用或最新模型能力。那些都重要，但只是图景的一部分。软件工程还包括需求、架构、测试、维护，以及澄清意图的艰难工作。研究的共识是：澄清开发者意图，与验证和确认一起，是可信 agent 软件工作流的核心。
作者的 Lutions 经验指向同一方向：难的部分很少是让 agent 提出一个改动，而是确定那个改动是否符合系统、需求和涉及的风险。这就是为什么上下文层、显式检查和评审角色不只是流程装饰——它们是人与 agent、代码库之间工作接口的一部分。一个有用的心智模型：agent 开发工作流不是模型加 prompt，是模型在上下文、工具、约束和反馈组成的系统里运行。
可迁移的部分不是工单系统本身
Lutions 既不是开源产品，也不是放之四海皆准的蓝图。可迁移的是工作上下文：agent 在遇到带显式规则和可验证后果的代码库时更有用，而不是空画布加乐观 prompt。小型演示项目往往太顺滑、暴露不了这些问题；大型生产系统可能太慢、太险、太贵。Lutions 介于两者之间：复杂到真实摩擦会出现，又贴近日常工作，不需要庞大协作机制就能从中学习。
来源：How a Ticket System Became My Agentic AI Lab - DEV Community