吉利科技大模型应用开发一面

1. 介绍一下你做的这个代码助手 Agent 项目

2. 你这是在网上找的项目还是哪里学的

3. 状态机是用于干什么的

状态机在 Agent 里最重要的作用，是把模型原本“想到哪做到哪”的行为，变成一个可观察、可控制的执行流程。特别是代码助手、文件助手、自动化办公这类场景，如果没有状态机，模型一旦中途拿到错误信息或者误判上下文，后面就可能一路错下去。用了状态机之后，你可以明确规定当前是分析态、规划态、确认态、执行态还是回滚态，每个状态允许什么动作，不允许什么动作。

我自己的理解是，状态机不是为了让系统显得高级，而是为了收敛复杂性。你要让模型做事情，就不能只靠 prompt 约束，还要靠流程边界约束。像“未确认前不能写文件”“测试失败要回到分析态”“高风险工具调用后进入等待用户态”，这些都适合状态机表达。

from enum import Enum

class AgentState(Enum):
    ANALYZE = "analyze"
    PLAN = "plan"
    CONFIRM = "confirm"
    EXECUTE = "execute"
    ROLLBACK = "rollback"
    DONE = "done"

4. 在流程中，AI 是否会再次询问用户，比如确认删除文件

会，而且我会把这种确认做成显式的流程节点，而不是只在 prompt 里说一句“谨慎操作”。因为只靠 prompt，模型在长流程里很容易忘。像删除文件、覆盖目录、批量重命名、执行写数据库脚本这类动作，我一般都会加二次确认，而且确认内容不能太抽象，要把具体影响范围讲清楚，比如删的是哪几个文件、影响哪些模块、是否可恢复。

另外确认也不能做得太烦，不然用户体验会很差。所以通常只对高风险动作做强确认，对低风险动作做弱确认或者自动放行。这个平衡点很重要，不然系统会在“太冒进”和“太啰嗦”之间来回摇摆。

dangerous_ops = {"delete_file", "rm_dir", "drop_table"}

def need_confirm(action_type: str) -> bool:
    return action_type in dangerous_ops

5. 在规划时，AI 是否会进一步细化动作

会，但我不太喜欢让模型一上来就把计划展开得特别细。因为计划太粗，后面执行容易跳步；计划太细，模型又容易在无关步骤上消耗太多 token，甚至把自己绕进去。比较实用的做法是先生成一个阶段性计划，比如“定位问题—收集证据—提出修改—执行测试—总结结果”，等进入某个阶段时再局部细化。

这种分层规划比一次性全展开更稳，原因很简单：环境信息是动态变化的。模型读完几个文件、拿到测试日志之后，原计划很可能就要改。如果一开始把每一步都写死，后面反而难调整。规划本身不是目的，能支持动态修正才有意义。

6. 你们使用的是什么框架

如果从 Agent 编排层说，我更倾向用轻量可控的工作流框架或者自己封一层 orchestrator，而不是把所有逻辑都压在一个黑盒框架里。因为代码助手这类场景特别依赖执行可控性，框架一旦封得太深，出了问题很难定位。一般会有几层：模型调用层、工具注册层、状态流转层、观察与日志层，再往下是沙箱和执行环境。

面试里如果继续问，我会强调我看重的是框架能不能支持这几件事：工具 schema 清晰、状态可追踪、失败能回放、上下文能裁剪、节点能打断重试。好不好用不是看生态有多热，而是看出线上问题的时候能不能修。