先说结论
使用 Code Agent 开发时，我们经常讨论 SDD、TDD 和多 Agent 编排。但这些解决的主要是“怎么描述任务、怎么验证结果、怎么分配工作”。
想让 Agent 真正完成半自动迭代，还有一个经常被忽略的前提：可观测性，也就是 Agent 对外部环境的感知能力。
Agent 能看见什么，决定了它能发现什么。它如果只能看到本地代码，却看不到远程服务器的编译过程、SOC 开发板的运行状态和真实日志，那么再强的推理能力也只能是盲人摸象。
目录
1. 传统流程里，Agent 是盲的
最常见的做法，是在本地运行 Agent，让它负责写代码和测试；编译则放在远程服务器上执行。
问题在于，Agent 通常看不到远程环境。
明显的编译错误，人一眼就能发现；真正容易被遗漏的，是一些不常见的 warning、隐蔽的配置错误，或者只有在特定环境中才会出现的异常。
SOC 开发板上也是一样。
传统流程往往是人盯着串口或日志，把自己认为“有问题”的部分复制给 Agent。但开发板的日志刷得很快，一些短暂却不合理的资源波动，可能几秒钟就过去了。
人在这里成了服务器、开发板与 Agent 之间的桥梁。但只要经过人工筛选，信息就一定会衰减：人没注意到的东西，Agent 永远也看不到。
2. 从人肉桥接到直接感知
更合理的做法，是在安全可控的前提下，让 Agent 直接观察真实环境。
对于远程编译服务器，可以让 Agent 通过 SSH 连接，但不要直接开放整台服务器。可以在外面封装一层受限脚本，只允许它：
- 进入指定目录；
- 执行固定的编译和测试命令；
- 读取构建状态与日志；
- 获取必要的产物和环境信息。
SOC 开发板也可以通过串口、SSH 或调试接口接入，让 Agent 直接读取进程状态、运行日志和测试结果。
重点不是给 Agent 无限权限，而是让它直接看到完成判断所必需的事实。
权限应该从小到大逐步开放：先只读，再开放固定操作，最后才根据实际需要增加能力。安全边界是给 Agent 装眼睛的前提，不是事后的补丁。
3. 可观测不等于读取全部日志
服务器和开发板都可能在短时间内产生大量日志。一次编译或测试出现几百、几千行输出非常正常。
如果让 Agent 实时读取全部内容，不仅浪费上下文，还可能让真正的问题淹没在噪声里。
一个简单但实用的策略是：
- 先把完整日志保存下来；
- 默认读取开头 100 行和结尾 100 行；
- 中间部分暂时不读；
- 发现异常后，再按照关键词、模块或时间范围读取相关片段。
也就是：完整日志负责追溯，分段日志负责分析。
开头通常包含环境、参数和初始化状态，结尾通常包含结果、错误和退出原因。先看两端，是最笨但也最实用的第一步。
在此基础上，还要限制单次日志大小、保存时间和并发数量，避免日志无限扩散。
4. 这套方法不只适用于开发
这套思路同样适用于 Jira 等 Bug 跟踪 Agent。
要让 Agent 自动分析问题，它就需要看到问题描述、历史评论、关联版本和处理状态。但 Jira 覆盖范围更广，可能包含多个项目和敏感信息，因此权限必须设置得更紧。
可以限制 Agent 只能读取指定项目，只能修改部分字段，并把“查看问题”“更新状态”和“关闭问题”分别授权。
场景虽然不同，原则仍然一样：
让 Agent 看见完成任务所需的信息，但只开放完成任务所需的权限。
5. 收个尾
只会写代码的 Agent，仍然只是一个更快的代码助手。
只有当它能够直接观察环境、执行操作、发现异常、完成修复并重新验证时，自动化迭代才真正形成闭环。
不要再让人充当中间层，替 Agent 转述服务器和开发板上发生了什么。
给 Agent 装上眼睛，也给这双眼睛划清边界。